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1. REAL PARTY IN INTEREST 

The real party in interest in the present appeal is the assignee, Sprint Communications 
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Trademark Office records. 
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11. RELATED APPEALS AND INTERFERENCES 

Applicant filed an Appeal Brief with the U.S. Patent and Trademark Office on February 
20, 2003. An Office Action was mailed on August 28, 2003, in which the Examiner indicated 
that "Applicant's argument in the Appeal Brief filed 2/24/03 is persuasive and, therefore, finality 
is withdrawn." The Examiner also cited a new ground of rejection (as discussed below). This 
Supplemental Appeal Brief is filed in response to the outstanding Office Action, pursuant to 
37C.F.R. § 1.193(b)(2). 

IIL STATUS OF CLAIMS 

Claims 79-1 15 are pending in the application. Claims 1-78 have been canceled. Claims 
79-115 stand rejected, as follows: claims 79-80, 82-88, 91-95, 98-99, 102-104, 106 and 108-114 
stand rejected under 35 U.S.C. § 102(e) as being anticipated by U.S. Patent No. 5,610,841 to 
Tanaka, et al\ claims 81, 89, 96, 100, 105, 107 and 1 15 stand rejected under 35 U.S.C. § 103(a) 
as being obvious over U.S. Patent No. 5,610,841 to Tanaka, et al \ and claims 90, 97 and 101 
stand rejected under 35 U.S.C. § 103(a) as being obvious over U.S. Patent No. 5,610,841 to 
Tanaka, et al in view of U.S. Patent No. 4,914,570 to Peacock This Supplemental Appeal Brief 
is directed to claims 79-1 15. 

IV. STATUS OF AMENDMENTS 

Claims 79-1 15 have not been amended. These claims are reproduced in Appendix A 
attached hereto. 
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V. SUMMARY OF THE INVENTION 

The present invention is directed to a system and method for providing network 
processing and stored data access that is configured to be fully scalable and/or fully survivable. 
Two different embodiments of the invention are shown in Figs. 1 and 2 of the application, 
attached hereto as Appendix B. As can be seen, at least one server (also referred to as an 
application processor) is provided that is operable to process user requests. The server is 
connected to a switch, which is in turn connected to at least one data storage device. 

In one aspect of the invention, the system is fully "scalable" in the sense that additional 
servers can be added to the system as demand for a particular application increases, without 
adding additional data storage devices . Conversely, servers can be removed from the system 
without removing data storage devices. In a similar manner, additional data storage devices can 
be added to the system as storage requirements for a particular application increase, without 
adding additional servers . Conversely, data storage devices can be removed from the system 
without removing servers. Thus, the system is scalable to increase or decrease server capacity 
without changing the data storage capacity, and/or is scalable to increase or decrease data storage 
capacity without changing the server capacity. 

In another aspect of the invention, the system includes at least two servers that apply 
substantially the same application(s) when processing user requests, and at least two data storage 
devices that contain substantially identical data. The system is fully "survivable" in the sense 
that, if any one of the servers fails, user requests can be processed by any of the other servers in 
the system that are operable. Likewise, if any one of the data storage devices fails, substantially 
identical data can be retrieved from any of the other data storage devices that are operable. Thus, 
the system is survivable and able to process user requests in the event of a failure of any one of 
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the servers, and is survivable and able to retrieve data in the event of a failure of any one of the 
data storage devices. 

Claims 79-85, 89-97, 102, 104-108, 1 10 and 1 12 are directed to the scalability aspect of 
the claimed invention. Claims 98-101 and 1 14-115 are directed to the survivability aspect of the 
claimed invention. Claims 86-88, 103, 109, 1 1 1 and 1 13 are directed to both the scalability and 
survivability aspects of the claimed invention. 

VI. ISSUES 

The issues on appeal are as follows: 

A. Whether claims 79-80, 82-88, 91-95, 98-99, 102-104, 106 and 108-114 are 
unpatentable under 35 U.S.C. § 102(e) as being anticipated by U.S. Patent No. 5,610,841 to 
Tanaka, et al. 

B. Whether claims 8 1 , 89, 96, 1 00, 1 05, 1 07 and 1 1 5 are unpatentable under 35 
U.S.C. § 103(a) as being obvious over U.S. Patent No. 5,610,841 to Tanaka, et al. 

C. Whether claims 90, 97 and 101 are unpatentable under 35 U.S.C. § 103(a) as 
being obvious over U.S. Patent No. 5,610,841 to Tanaka, et al. in view of U.S. Patent No. 
4,914,570 io Peacock. 

VII. GROUPING OF THE CLAIMS 

With respect to the rejection stated in Issue A, claims 79-80, 82-85, 91-95, 102, 104, 106, 
108, 1 10 and 1 12 stand or fall together; claims 98-99 and 1 14 stand or fall together; and claims 
86-88, 103, 109, 1 1 1 and 1 13 stand or fall together. As discussed in Section VIII.A.4 below, 
these three different groups of claims are separately patentable. 
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With respect to the rejection stated in Issue B, claims 81, 89, 96, 105 and 107 stand or fall 
together; and claims 100 and 115 stand or fall together. As discussed in Section VIILB.3 below, 
these two different groups of claims are separately patentable. 

With respect to the rejection stated in Issue C, claims 90 and 97 stand or fall together; and 
claim 101 stands or falls alone. As discussed in Section VIILC.3 below, these two different 
groups of claims are separately patentable. 

VIII. ARGUMENT 
A. Applicant's Ctaims are not Anticipated by Tanaka 

The Examiner rejected claims 79-80, 82-88, 91-95, 98-99, 102-104, 106 and 108-114 
under 35 U.S.C. § 102(e) as being anticipated by U.S. Patent No. 5,610,841 to Tanaka, et al 
{^'Tanaka''), attached hereto as Appendix C. However, as discussed below, Tanaka does not 
disclose the survivability and/or scalability aspects of the claimed invention. 
1 . The Tanaka Disclosure 

Tanaka discloses a video server for the storage and transmission of compressed video 
programs. As shown in Fig. 2, the video server includes a plurality of media segment file servers 
(MSFS) (1000-1005. . .), a system manager (SM) (2000), and a plurality of sequence control 
brokers (SCB) (3000-3002. . .), all of which transmit data to each other via an ATM switch 
(4000). Tanaka, col. 9, 11. 52-58. As shown in Fig. 1, each video program is divided into a 
plurality of media segment files (MSF). Tanaka, col. 9, 11. 40-51. Each MSF is stored separately 
on a MSFS located within the video server. Tanaka, col. 9, 1. 63 to col. 10, 1. 11. For example, as 
shown in Fig. 3, program 1 is divided into 2000 MSF's, wherein MSF(l) is stored on MSFS 
(1000), MSF(2) is stored on MSFS (1001), MSF(3) is stored on MSFS (1002), and so on. Id. 
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In operation, a user at a subscriber terminal sends a request for a video program to the 

video server. Tanaka, col. 10, 11. 15-62. The request is received by one of the SCB's, which 

requests a sequential control file (SCF) for the requested video program from the SM (2000). Id. 

The SCF contains media signal file pointers that indicate the location of each of the MSF's for 

the requested video program in the array of MSFS's. Id. The SCF is then transmitted to the 

MSFS's, which, in turn, transmit the stored MSF's for the requested video program to the SCB. 

The SCB then sequentially aligns the MSF's for transmission of the video program to the 

subscriber terminal. Id. 

2. Tanaka Does Not Disclose the Scalability Aspect of the Claimed 
Invention 

Independent claims 79, 82, 91, 102, 104 and 106 (and dependent claims 80, 83-88, 92- 
95, 103 and 108-1 13), which are directed to the scalability aspect of the claimed invention,^ each 
require that a server operates independently of a data storage device so as to permit the addition 
(or removal) of a server without the addition (or removal) of a data storage device (e.g., as 
demand for a particular application increases or decreases). Tanaka does not disclose or suggest 
this limitation. 

The Examiner cites to two portions of the "Summary of the Invention" in Tanaka to 
support his contention that Tanaka discloses the claimed invention. However, as shown below, 
neither of these portions disclose a server that operates independently of a data storage device to 
permit the addition (or removal) of a server without the addition (or removal) of a data storage, 
as claimed by AppHcant: 



V Dependent claims 86-88, 103, 109, 11 1 and 1 13 are also directed to the survivability aspect of the claimed 
invention, discussed in Section VIII. A.3 below. 
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1. Tanaka. col. 4, IL 22-30 

The first cited paragraph discloses that when there are a plurality of requests for 
the same video program, each frame block server reads out the frame blocks {e.g., 
MSF's) independently and sends the same to each subscriber terminal 
simultaneously. This allows multiple subscribers to access the same video 
program at the same time. The second cited paragraph discloses that because the 
ATM switch operates asynchronously, the number of subscribers and the kinds of 
video programs can easily be changed. 

2. Tanaka, coL 7, 11. 1-7 

The first cited paragraph discloses that a disk array may comprise K disk drives 
for storing the frame blocks (e.g., MSF's), and the address of each frame block 
may be formatted for a readout command. The second cited paragraph discloses 
that the frame blocks {e.g., MSF's) can be transferred between a plurality of ATM 
switches to extend the scale of the video server. 

Significantly, the Examiner does not cite to any portion of Tanaka that even remotely discloses 

or suggests the claimed invention. Rather, the portions cited by the Examiner relate to the frame 

blocks {e.g., MSF's) and the manner in which they can be read out through the ATM switch for 

transmission to a subscriber terminal. 

Thus, independent claims 79, 82, 91, 102, 104 and 106 (and dependent claims 80, 83-88, 

92-95 and 108-1 13) are not anticipated by Tanaka and should be allowed. 

3. Tanaka Does Not Disclose the Survivability Aspect of the Claimed 
Invention 

Independent claims 98 and 1 14 (and dependent claims 86-88, 99, 109, 103, 1 1 1 and 113), 
which are directed to the survivability aspect of the claimed invention,^ each require first and 
second (or a plurality of) data storage devices that each store substantially the same data such 
that, in the event of a failure of any one of the data storage devices, the data is accessible from 
any other of the data storage devices that are operable. Tanaka does not disclose or suggest this 



^/ Dependent claims 86-88, 103, 109, 11 1 and 113 are also directed to the scalability aspect of the claimed 
invention, discussed in Section VIII.A.2 above. 
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limitation. Rather, in Tanaka, each MSFS stores a different combination of MSFs such that no 
one MSFS stores substantially the same MSF*s as any other MSFS. 

For example, as shown in Fig. 3, MSFS (1000) stores MSF(l) and MSF(lOOl) of 
program 1, MSF(l) of program 2, and MSF(l) of program 3. By contrast, MSFS (1001) stores 
MSF(2) and MSF(1002) of program 1, MSF(2) of program 2, and MSF(2) of program 3. MSFS 
(1002) and MSFS (1999) (as well as the remaining MSFS's) also each store a unique 
combination of MSF's. As such, Tanaka teaches against the storage of substantially the same 
data in each of the data storage devices for protection against equipment failure, as claimed by 
Applicant. 

Thus, independent claims 98 and 1 14 (and dependent claims 86-88, 99, 103, 109, 111, 
and 113) are not anticipated by Tanaka and should be allowed. 

4. Different Groups of Claims are Separately Patentable 

Claims 79-80, 82-85, 91-95,102, 104, 106, 108, 110 and 112 are directed to the 
scalability aspect of the claimed invention, and are not anticipated by Tanaka for the reasons 
discussed in Section VIII. A.2 above. Claims 98, 99 and 1 14 are directed to the survivability 
aspect of the claimed invention, and are not anticipated by Tanaka for the reasons discussed in 
Section VIII.A.3 above. Claims 86-88, 103, 109, 1 1 1 and 1 13 are directed to both the scalability 
and survivability aspects of the claimed invention, and are not anticipated by Tanaka for the 
reasons discussed in Sections VIII.A.2 and VIILA.3 above. 

B. Applicant's Claims are not Obvious Over Tanaka 

The Examiner rejected claims 81, 89, 96, 100, 105, 107 and 115 under 35 U.S.C. § 103(a) 
as being obvious over Tanaka (described in Section VIIL A. 1 above). A prima facie case of 
obviousness for rejecting these claims has not been established in that Tanaka does not disclose 
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or suggest Applicant's claimed invention. The Patent and Trademark Office's burden of 
establishing a prima facie case of obviousness is not met unless "'the teachings from the prior art 
itself would appear to have suggested the claimed subject matter to a person of ordinary skill in 
the art.'" In re Bell 26 U.S.P.Q. 2d 1529, 1531 (Fed. Cir. 1993)(quoting In re Rinehart . 189 
U.S.P.Q. 143,147 (C.C.P.A. 1976)). 

1. Tanaka Does Not Disclose or Suggest the Scalability Aspect of the 
Claimed Invention 

Dependent claims 81, 89, 96, 105 and 107 are directed to the scalability aspect of the 
claimed invention. Claim 81 depends from independent claim 79; claim 89 depends from 
independent claim 82; claim 96 depends from independent claim 91; claim 105 depends from 
independent claim 104; and claim 107 depends from independent claim 106. Each of these 
independent claims (and thus each of dependent claims 81, 89, 96, 105 and 107) require that a 
server operates independently of a data storage device so as to permit the addition (or removal) 
of a server v^ithout the addition (or removal) of a data storage device. As discussed in Section 
VIILA.2 above, the Examiner does not cite to any portion of Tanaka that even remotely discloses 
or suggests this limitation. Thus, the Examiner has failed to meet his burden of estabUshing a 
prima facie case of obviousness, and claims 81, 89, 96, 105 and 107 should be allowed. 

2. Tanaka Does Not Disclose or Suggest the Survivability Aspect of the 
Claimed Invention 

Dependent claims 100 and 1 15 are directed to the survivability aspect of the claimed 
invention. Claim 100 depends from independent claim 98; and claim 115 depends from 
independent claim 1 14. Each of these independent claims (and thus each of dependent claims 
100 and 1 15) require first and second (or a plurality of) data storage devices that each store 
substantially the same data such that, in the event of a failure of any one of the data storage 
devices, the data is accessible from any other of the data storage devices that are operable. As 
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discussed in Section VIII.A.3 above, Tanaka does not disclose or suggest this limitation. Rather, 
in Tanaka, each MSFS stores a different combination of MSF's such that no one MSFS stores 
substantially the same MSF's as any other MSFS. Thus, because the Examiner has failed to meet 
his burden of establishing a prima facie case of obviousness, claims 100 and 1 15 should be 
allowed. 

3. Different Groups of Claims are Separately Patentable 

Claims 81, 89, 96, 105 and 107 are directed to the scalability aspect of the claimed 
invention, and are not obvious over Tanaka for the reasons discussed in Section VIII.B.l above. 
Claims 100 and 1 15 are directed to the survivability aspect of the claimed invention, and are not 
obvious over Tanaka for the reasons discussed in Section VIII.B.2 above. 

C, Applicant's Claims are not Obvious Over Tanaka in View oi Peacock 
The Examiner rejected claims 90, 97 and 101 under 35 U.S. C. § 103(a) as being obvious 
over Tanaka (described in Section VIII.A.l above) in view of U.S. Patent No. 4,914,570 to 
Peacock {''Peacock''), attached hereto as Appendix D. Peacock discloses a multiple processor 
computer system, A prima facie case of obviousness for rejecting these claims has not been 
established in that Tanaka and Peacock do not alone or in combination disclose or suggest 
Applicant's claimed invention. Furthermore, these cited references are not properly combinable. 
The Patent and Trademark Office's burden of establishing a prima facie case of obviousness is 
not met unless '"the teachings from the prior art itself would appear to have suggested the 
claimed subject matter to a person of ordinary skill in the art.'" In re Bell , 26 U.S.P.Q. 2d 1529, 
1531 (Fed. Cir. 1993)(quoting In re Rinehart . 189 U.S.P.Q. 143,147 (C.C.PA. 1976)). 
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1. Tanaka and Peacock Do Not Disclose or Suggest the Scalability Aspect 
of the Claimed Invention and are not Properly Combinable 

Dependent claims 90 and 97 are directed to the scalability aspect of the claimed 

invention. Claim 90 depends from independent claim 82; and claim 97 depends from 

independent claim 91. Each of these independent claims (and thus each of dependent claims 90 

and 97) require that a server operates independently of a data storage device so as to permit the 

addition (or removal) of a server without the addition (or removal) of a data storage device. 

Neither Tanaka nor Peacock disclose or suggest this limitation. As discussed in Section 

VIII. A.2 above, the Examiner does not cite to any portion of Tanaka that even remotely discloses 

or suggests this limitation. Peacock merely discloses a multiple processor computer system in 

which each of the processors has its own associated memory, but also has access to the memories 

of the other processors. Thus, Applicant's claimed invention is clearly distinguishable from 

Tanaka and Peacock. 

Furthermore, "[bjefore the PTO may combine the disclosures of two or more prior 

art references in order to establish prima facie obviousness, there must be some suggestion for 

doing so, found either in the references themselves or in the knowledge generally available to 

one of ordinary skill in the art." In re Jones . 21 U.S.P.Q. 2d 1941, 1943-44 (Fed. Cir. 1992). If 

there is no technological motivation for modifying a reference, then the reference should not be 

part of a §103 rejection. In the present case, there is no motivation to combine Tanaka and 

Peacock. Tanaka discloses the various components of a video server. By contrast, Peacock 

discloses the inner- workings of a multiple processor computer system. Nothing in either 

reference suggests that any one of the various components of Tanaka could be modified in 

accordance with the teachings of Peacock. 
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Still further, even if the references were somehow combined, the combination of Tanaka 
and Peacock does not disclose or suggest Applicant's claimed invention. Specifically, the 
combination does not disclose or suggest a server that operates independently of a data storage 
device so as to permit the addition (or removal) of a server without the addition (or removal) of a 
data storage device, as claimed by Applicant. 

Thus, the Examiner has failed to meet his burden of estabUshing a prima facie case of 

obviousness, and claims 90 and 97 should be allowed. 

2. Tanaka and Peacock Do Not Disclose or Suggest the Survivability 
Aspect of the Claimed Invention and are not Properly Combinable 

Dependent claim 101 is directed to the survivability aspect of the claimed invention. 
Claim 101 depends from independent claim 98, which requires a plurality of data storage devices 
that each store substantially the same data such that, in the event of a failure of any one of the 
data storage devices, the data is accessible from any other of the data storage devices that are 
operable. Neither Tanaka nor Peacock disclose or suggest this limitation. As discussed in 
Section VIILA.3 above, in Tanaka, each MSFS stores a different combination of MSF's such that 
no one MSFS stores substantially the same MSF's as any other MSFS. Peacock merely discloses 
a multiple processor computer system in which each of the processors has its own associated 
memory. Thus, Applicant's claimed invention is clearly distinguishable from Tanaka and 
Peacock, 

Fmthermore, "[bjefore the PTO may combine the disclosures of two or more prior 
art references in order to establish prima facie obviousness, there must be some suggestion for 
doing so, found either in the references themselves or in the knowledge generally available to 
one of ordinary skill in the art." In re Jones , 21 U.S.P.Q. 2d 1941, 1943-44 (Fed. Cir. 1992). If 
there is no technological motivation for modifying a reference, then the reference should not be 
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part of a §103 rejection. In the present case, there is no motivation to combine Tanaka and 
Peacock, Tanaka discloses the various components of a video server. By contrast, Peacock 
discloses the inner-v^orkings of a multiple processor computer system. Nothing in either 
reference suggests that any one of the various components of Tanaka could be modified in 
accordance with the teachings of Peacock, 

Still further, even if the references were somehow combined, the combination of 
Tanaka and Peacock does not disclose or suggest Applicant's claimed invention. Specifically, 
the combination does not disclose or suggest a plurality of data storage devices that each store 
substantially the same data such that, in the event of a failure of any one of the data storage 
devices, the data is accessible from any other of the data storage devices that are operable, as 
claimed by Applicant. 

Thus, the Examiner has failed to meet his burden of establishing a prima facie case of 
obviousness, and claim 101 should be allowed. 

3. Different Groups of Claims are Separately Patentable 

Claims 90 and 97 are directed to the scalability aspect of the claimed invention, and are 
not obvious over Tanaka in view of Peacock for the reasons discussed in Section VIII.C.l above. 
Claim 101 is directed to the survivability aspect of the claimed invention, and is not obvious over 
Tanaka in view of Peacock for the reasons discussed in Section VIILC.2 above. 
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IX. 



APPENDICES 



Attached hereto are the following Appendices: 
Appendix A - Claims on Appeal 
Appendix B - Figs. 1 and 2 of the Application 
Appendix C - U.S. Patent No. 5,699,503 to Tanaka, et al. 
Appendix D - U.S. Patent No. 4,914,570 to Peacock 



For the foregoing reasons, Applicant respectfully submits that claims 79-1 15 are 
patentable over the cited references and should be allowed. Accordingly, Applicant respectfully 
requests that the Board reverse the Examiner's rejections of claims 79-1 15, and allow claims 79- 



X. 



SUMMARY 



115. 



Respectfully submitted, 




Judith L. Carlson, Reg. No. 41,904 
STINSON MORRISON HECKER LLP 
1201 Walnut Street, Suite 2800 
P.O. Box 419251 
Kansas City, MO 64141-6251 
Telephone: (816) 842-8600 
Facsimile: (816)691-3495 
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APPENDIX A 

Claims on Appeal 



The text of the claims on appeal are as follows: 

79. A scalable system for providing network processing and stored data access, the system 
comprising: 

(a) a server operative to process user requests; 

(b) a switch operatively connected to the server; 

(c) a data storage device operatively connected to the switch; and 

(d) wherein the server operates independently of the data storage device and is 
connected to the data storage device via the switch in a manner to permit the inclusion of an 
additional server to process other user requests without the inclusion of an additional data storage 
device. 

8 0. The system of Claim 79 wherein the server operates independently of the data 
storage device and is connected to the data storage device via the switch in a manner to permit 
the inclusion of an additional data storage device without the inclusion of an additional server. 

81. The system of Claim 79 wherein the server appHes an application to the user 
requests, the application selected from the group consisting of: a mail application, a news 
application, a directory application, a content application, a groupware application, and an 
internet protocol (IP) service. 



82. A scalable system for providing network processing and stored data access, the 

system comprising: 

(a) at least first and second servers operative to process at least first and 
second user requests, respectively; 

(b) a switch operatively connected to each of the servers; 

(c) a plurality of data storage devices operatively connected to the switch; and 

(d) wherein the servers operate independently of the data storage devices and 
are connected to the data storage devices via the switch in a manner to permit the inclusion of an 
additional server to process at least an additional user request without the inclusion of an 
additional data storage device. 

83. The system of Claim 82 wherein the servers operate independently of the data 
storage devices and are connected to the data storage devices via the switch in a manner to 
permit the inclusion of an additional data storage device without the inclusion of an additional 
server. 

84. The system of Claim 83 wherein the servers operate independently of the data 
storage devices and are connected to the data storage devices via the switch in a manner to 
permit the removal of any one of the plurality of data storage devices without the removal of any 
of the servers. 



85. The system of Claim 82 wherein the servers operate independently of the data 
storage devices and are connected to the data storage devices via the switch in a manner to 
permit the removal of any one of the servers without the removal of any of the data storage 
devices. 

86. The system of Claim 82 wherein each of the first and second servers applies an 
application, the application applied by the first server being substantially the same as the 
application applied by the second server such that, in the event of a failure of either of the first 
and second servers, any subsequent user requests will be processed by any other of the servers 
that are operable. 

87. The system of Claim 82 wherein each of the plurahty of data storage devices 
stores data, the data stored by each of the plurality of data storage devices being substantially the 
same such that, in the event of a failure of any one of the plurality of data storage devices, the 
data is accessible fi-om any other of the plurality of data storage devices that are operable. 

88. The system of Claim 82 wherein each of the first and second servers applies an 
application, the application applied by the first server being substantially the same as the 
application applied by the second server such that, in the event of a failure of either of the first 
and second servers, any subsequent user requests will be processed by any other of the servers 
that are operable, and wherein each of the plurality of data storage devices stores data, the data 
stored by each of the plurality of data storage devices being substantially the same such that, in 



the event of a failure of any one of the pluraUty of data storage devices, the data is accessible 
from any other of the plurality of data storage devices that are operable. 

89. The system of Claim 82 wherein each of the at least first and second servers 
applies an application selected from the group consisting of; a mail application, a news 
application, a directory application, a content application, a groupware application, and an 
internet protocol (IP) service. 

90. The system of Claim 82 further comprising a load balancer operatively connected 
to each of the at least first and second servers, the load balancer operative to route an additional 
user request to the one of the at least first and second servers with the least load. 

91 . A scalable system for providing network processing and stored data access, the 
system comprising: 

(a) at least first and second sets of servers, each of the sets of servers 
comprising at least first and second servers operative to process at least first and second user 
requests, respectively, and wherein each of the sets of servers appHes a separate application; 

(b) a switch operatively connected to each of the servers within each of the 

sets of servers; 

(c) a plurality of data storage devices operatively connected to the switch; and 

(d) wherein the sets of servers operate independently of the data storage 
devices and are connected to the data storage devices via the switch in a manner to permit the 



inclusion of an additional server to any of the sets of servers to process at least an additional user 
request without the inclusion of an additional data storage device. 

92. The system of Claim 91 wherein the sets of servers operate independently of the 
data storage devices and are connected to the data storage devices via the switch in a manner to 
permit the inclusion of an additional data storage device without the inclusion of an additional 
server to any of the sets of servers. 

93. The system of Claim 92 wherein the sets of servers operate independently of the 
data storage devices and are connected to the data storage devices via the switch in a manner to 
permit the removal of any one of the plurality of data storage devices without the removal of any 
of the servers from any of the sets of servers. 

94. The system of Claim 93 wherein the data stored by any one of the plurality of data 
storage devices is associated with an application applied by any one of the sets of servers. 

95. The system of Claim 91 wherein the sets of servers operate independently of the 
data storage devices and are connected to the data storage devices via the switch in a manner to 
permit the removal of any one of the servers from any one of the sets of servers without the 
removal of any of the pluraUty of data storage devices. 



96. The system of Claim 91 wherein each of the at least first and second servers of 
any one of the sets of servers applies an application selected from the group consisting of: a mail 
application, a news application, a directory application, a content application, a groupware 
application, and an internet protocol (IP) service. 

97. The system of Claim 91 wherein each of the at least first and second servers of 
any one of the sets of servers applies an application, and wherein the system further comprises a 
load balancer operatively connected to each of the at least first and second servers of each of the 
sets of servers, the load balancer operative to route user requests to the one of the at least first 
and second servers of the sets of servers with the least load for a particular application. 

98. A survivable system for providing network processing and stored data access, the 
system comprising: 

(a) at least first and second servers operative to process at least first and 
second user requests, respectively, 

(b) a switch operatively connected to each of the servers; 

(c) a plurality of data storage devices operatively connected to the switch; 

(d) wherein each of the first and second servers applies an application, the 
application applied by the first server being substantially the same as the application 
applied by the second server such that, in the event of a failure of either of the first and 
second servers, any subsequent user requests will be processed by any other of the 
servers that are operable; and 



(e) wherein each of the plurality of data storage devices stores data, the data 
stored by each of the plurality of data storage devices being substantially the same such 
that, in the event of a failure of any one of tlie plurality of data storage devices, the data is 
accessible from any other of the plurality of data storage devices that are operable. 

99. The system of Claim 98 wherein the data stored by any one of the plurality of data 
storage devices is associated with an application applied by any one of the first and second 
servers. 

100. The system of Claim 98 wherein each of the at least first and second servers 
applies an application selected from the group consisting of: a mail application, a news 
application, a directory application, a content application, a groupware application, and an 
internet protocol (IP) service. 

101. The system of Claim 98 further comprising a load balancer operatively connected 
to each of the at least first and second servers, the load balancer operative to route user requests 
to the one of the at least first and second servers corresponding to the server with the least load. 

102. A scalable system for providing network processing and stored data access, the 
system comprising: 

(a) at least first and second servers operative to process at least first and 
second user requests, respectively; 

(b) a switch operatively connected to each of the servers; 



(c) a plurality of data storage devices operatively connected to the switch; 

(d) a load balancer operatively connected to each of the at least first and 
second servers, the load balancer operative to route user requests to the one of the at least first 
and second servers with the least load; and 

(e) wherein the servers operate independently of the data storage devices and 
are connected to the data storage devices via the switch in a manner to permit the inclusion of an 
additional server to process at least an additional user request without the inclusion of an 
additional data storage device, to permit the inclusion of an additional data storage device 
without the inclusion of an additional server, to permit the removal of any one of the servers 
without the removal of any of the data storage devices, and to permit the removal of any one of 
the data storage devices without the removal of any of the servers. 

103. The system of Claim 102 wherein each of the first and second servers applies an 
application, the application applied by the first server being substantially the same as the 
application appHed by the second server such that, in the event of a failure of either of the first 
and second servers, any subsequent user requests will be processed by any other of the servers 
that are operable, and wherein each of the plurality of data storage devices stores data, the data 
stored by each of the plurahty of data storage devices being substantially the same such that, in 
the event of a failure of any one of the plurality of data storage devices, the data is accessible 
fi-om any other of the plurality of data storage devices that are operable. 



1 04. A method for providing network processing and stored data access, the method 
comprising the steps of: 

(a) providing a server operative to apply an apphcation; 

(b) receiving a user request on the server; 

(c) applying the application to the user request to generate a query; 

(d) providing a data storage device configured to store data; 

(e) switching the query to the data storage device; 

(f) routing requested data fi-om the data storage device to the server in 
response to the query; and 

(g) providing an additional server without providing an additional data storage 
device, or alternatively, providing an additional data storage device without providing an 
additional server. 

105. The method of Claim 104 wherein the application is selected from the group 
consisting of; a mail application, a news application, a directory application, a content 
application, a groupware application, and an internet protocol (IP) service, 

106. A method for providing network processing and stored data access, the method 
comprising the steps of: 

(a) providing at least first and second servers operative to apply first and 
second applications, respectively; 

(b) receiving first and second user requests on the first and second servers, 

respectively; 



(c) applying the first and second applications to the first and second user 
requests, respectively, to generate first and second queries, respectively; 

(d) providing at least first and second data storage devices configured to store 
first and second data, respectively; 

(e) switching the first and second queries to the first and second data storage 
devices, respectively; 

(f) routing first requested data from the first data storage device to the first 
server in response to the first query, and routing second requested data from the second 
data storage device to the second server in response to the second query; and 

(g) providing an additional server without providing an additional data storage 
device, or alternatively, providing an additional data storage device without providing an 
additional server. 

107. The method of Claim 106 wherein each of the first and second applications is 
selected from the group consisting of a mail application, a news application, a directory 
application, a content application, a groupware application, and an internet protocol (IP) service. 

108. The method of Claim 106 wherein the first application is substantially the same as 
the second application. 

1 09. The method of Claim 1 08 fiirther comprising the step of 

(h) in the event of a failure of either of the first and second servers, processing 
any subsequent user requests on any other of the servers that are operable. 



1 10. The method of Claim 106 wherein the first data is substantially the same as the 
second data, 

1 1 L The method of Claim 1 1 0 further comprising the step of: 

(h) in the event of a failure of either of the first and second data storage 
devices, providing any subsequent requested data fi-om any other of the data storage devices that 
are operable. 

1 12. The method of Claim 106 wherein the first application is substantially the same as 
the second apphcation, and wherein the first data is substantially the same as the second data. 

113. The method of Claim 1 1 2 fiirther comprising the steps of: 

(h) in the event of a failure of either of the first and second servers, processing 
subsequent requests on any other of the servers that are operable; and 

(i) in the event of a failure of either of the first and second data storage 
devices, providing any subsequent requested data fi-om any other of the data storage devices that 
are operable. 

114. A method for providing network processing and stored data access, the method 
comprising the steps of: 

(a) providing at least first and second servers operative to apply first and 
second applications, respectively, the first application being substantially the same as the second 
application; 



(b) receiving first and second user requests on the first and second servers, 

respectively; 

(c) applying the first and second applications to the first and second user 
requests, respectively, to generate first and second queries, respectively; 

(d) providing at least first and second data storage devices configured to store 
first and second data, respectively, the first data being substantially the same as the second data; 

(e) switching the first and second queries to the first and second data storage 
devices, respectively; 

(f) routing first requested data fi-om the first data storage device to the first 
server in response to the first query, and routing second requested data fi'om the second 
data storage device to the second server in response to the second query; 

(g) in the event of a failure of either of the first and second servers, processing 
any subsequent requests on any other of the servers that are operable; and 

(h) in the event of a failure of either of the first and second data storage 
devices, providing any subsequent requested data fi'om any other of the data storage 
devices that are operable. 

115. The method of Claim 1 14 wherein each of the first and second applications is 
selected from the group consisting of: a mail application, a news application, a directory 
application, a content application, a groupware application, and an internet protocol (BP) service. 
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VIDEO SERVER 

BACKGROUND OF THE INVENTION 

(1) Field of the Invention 5 
The present invention relates to a video server which can 

transmit a video as per request among a plurality of videos 
stored therein. 

(2) Description of the Related Ait 

There has been active research for an interactive televi- 
sion system in the field of CATV (Cable Television) system, 
and the core of the system is a video server. 

In the interactive television system, each subscriber 
requests a video (program) he would like to watch to the 
CATV station, and the station transmits the videos as per 
requests to individual subscribers. Hms, the interactive 
television system enables the subscribers to enjoy the videos 
at any convenient time once it is put into practical use. 

Among various applications of the interactive television 20 
system, the on-demand television system has been already 
made available to the public. The on-demand television 
system comprises a video tape library, a plurality of video 
tqje players for playing the video tapes, a plurality of TV 
(television) cables for transmitting a plurality of videos 25 
being played to terminals equipped at the subscribers' end, 
and a switch for switching the TV cables. 

The entire system is controlled manually by a plurality of 
operators at the station. To be more specific, upon receipt of 
the requests firom the subscribers, the operators connea the 30 
TV cables to the their terminals by means of the switch, and 
play the video as per their requests by means of the video 
. tape players. Accordingly, each video being played is trans- 
mitted to their respective subscribers via the connected TV 
cables. 35 

However, such a manual control limits the service of the 
on-demand television system to a small number of subscrib- 
ers. For example, it is well assumed to receive 1(X) requests 
at a time if there are 1000 subscribers. However, it is almost 
in^ssible to manage all the requests simultaneously under ^ 
the manual control; there is a considerable lag time between 
the time the requests are received and the transmission of the 
requested videos. 

Given these circumstances, the pure-on-demand televi- 
sion system was proposed in '"Nikkei Communication" No. 
144. pp. 38-55, Feb. 15. 1993, and '*Nikkei Electronics", 
No. 584, pp. 58 as an ideal interact ve television system, and 
it has been attracting public interests. 

The pure-on-demand television system comprises a stor- ^ 
age unit for storing digital data of the videos, a plurality of 
cables for transmitting the digital video data to individual 
subscribers, a plurality of decoders for generating visible 
images by decoding the transmitted digital video data, and 
an ATM (Asynchmous Transfer Mode) switch for switching 
the cables. 

Since the videos are transmitted in the form of digital 
data, they are processed quickly, and the subscribers can not 
only play the videos in real time whenever they want, but 
also play the videos quickly in both directions (fast-forward 50 
and ^t-rewind) in real time as if they were manipulating the 
video tape player. 

However, even with this ideal system the problem of the 
time lag is not solved. This is because a myriad of requests 
are sent to one storage unit at a time, and it takes time to read 65 
out the requested video data from the storage unit. In 
addition, it takes time to transmit the readout data to the 
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subscribers by the means of the ATM switch when there is 
considerable traffic therein. Thus, the time lags caused in 
both reading out and transmitting the video data make the 
real time transmission impossible. 

SUMMARY OF THE INVENTION 

Accordingly, the present invention has a first object to 
provide a video server that can send video data in real time 
when a plurality of requests are received at a time. 

The present invention has a second object to provide a 
video server that can rewrite the video data while transmit- 
ting the same. 

The present invention has a third object to provide a video 
servo* that can construct a large scale interactive television 
system. 

The first object can be fulfilled by a video server which 
transmits digital video data stored therein to subscriber 
terminals as per video requests comprising: a plurality of 
frame block servers, each including an image memory and 
a readout control unit for the image memory, each Intage 
memory storing a plurality of frame blocks, each frame 
block being one of sections forming a piece of digital video 
data, the readout control unit receiving readout requests and 
in response reading out requested frame blocks from the 
image memory; a management unit for storing management 
data specifying which frame block server stores which frame 
block in the image memory; a plurality of subscriber inter- 
faces for receiving the video requests from the subscriber 
terminals, and in response sending readout requests to the 
frame block servers to readout the firame blocks forming 
requested digital image data in a predetermined sequence 
vMlc referring to the management data, and for transmitting 
the frame blocks transmitted from the frame block servers to 
the subscriber terminals at such timing that ensures a con- 
tinuous play; and an exchaxige unit for interconnecting each 
block server and each subscriber interface to transfer the 
frame blocks read out fipom the frame block servers as per 
the readout requests to the request-sender subscriber inter- 
faces. 

The management data may comprise a plurality of block 
pointers, each identifying a location of each frame block 
respectively, and including an address of each frame block 
serv^ that stores each frame block respectively, and each 
subscriber interface may include: a management data obtain- 
ment unit for receiving the video request from the subscriber 
terminal, and in response retrieving block pointers for the 
requested piece of (hgital video data from the management 
unit; a readout request generation unit for generating a 
readout request for each retrieved block pointer addressing 
to the frame block server specified by the address included 
therein; a readout request transmission unit for transmitting 
the readout requests to the specified frame block servers, one 
readout request being transmitted at a time; and a frame 
block ou^ut unit for receiving the frame blocks read out as 
per the readout requests, and in response Quitting the 
frame blocks to the request-sender subscriber terminal at 
predetermined timing. 

The frame block output unit may include: a frame block 
receipt unit for receiving the frame blocks addressed to the 
self s subscriber interface; a block buffer for accumulating a 
certain number of firame blocks received by the frame block 
receipt unit; an accumxilated amount judgment unit for 
judging whether the block buffer stores more than a prede- 
termined number of frame blocks; and an ou^ut unit for 
outputting the certain number of the frame blocks accunm- 
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lated in the block buffer when the accumulated amount 
judgment unit judges that the block buffer stores more than 
the predetermined number of &ame blocks, one £rame block 
being outputted at a time to the lequest-sender subscriber 
terminal* 5 

Each subsmber interface may be connected to a plurality 
of subscriber terminals, each subscriber terminal ouiputtmg 
a video request including a terminal identifier, and the 
managecaent data obtairmient unit may further include an 
identLQer detection unit for detecting the terminal identifiers 
contained in the video requests sent from the subscriber 
terminals upon receipt thereof, and the readout request 
transmission unit may further include an identifier attach- 
ment unit for attaching the terminal identifiers detected by 
the identifier detection unit to reach readout request gener- 
ated by the readout request generation unit, and the r^out 
control unit in each frame block server may include: a 
readout request receipt unit for detecting the terminal iden- 
tifiers when receiving the readout requests from the readout 
request transmission unit; and a frame block transmission 
unit for attaching the terminal identifiers detected by the ^ 
readout request receipt unit to each request frame block read 
out as per the readout requests before the transmission 
thereof to the request-sender subsoiber interface, and the 
frame block output unit may further include a distribution 
output control unit for receiving the terminal-identifier- ^ 
attached frame blocks and in response outputting the same 
to the request-sender subscriber terminal identified by the 
terminal identifier. 

Hie exchange unit may be an ATM cell switch for ^ 
exchanging cells, and each image memory may be a disk 
array comprising K disk drives for storing the frame blocks, 
and each block pointer may include an address of each frame 
block server storing each frame block, and an address of the 
frame block in the disk array, and the readout request may 
be of a cell structure, and the readout request transmission 
unit writes the address of the frame block server in a header 
area of the cell structure while writing the address of ±e 
frame block in the disk array in a data area of the cell 
structure to generate a readout request for each block ^ 
pointer, and the readout control unit in the frame block 
server may detect the address of the frame block in each 
readout request and read out the requested frame block by 
accessing to the address of the disk array. 

The readout control unit in each frame block server may 45 
hiclude: K queues for holding the readout requests to read 
out the requested frame blocks from corresponding disk 
drives in an order of receipt, one queue being furnished for 
one disk drive; a readout request receipt unit for receiving 
the readout requests addressed to the self s frame block 50 
server, an address analysis unit for detecting the address of 
the requested frame block contained in each readout request 
received by the readout request receipt unit and in response 
specifying the disk drives to which each readout request is 
addressed using the detected address, and for having the 55 
queue furnished for the specified disk drive store the readout 
request; a disk access unit for retrieving one readout request 
from the K queues, and in response accessing to a memory 
area in the specified disk drive at the address contained in the 
readout request to have the disk drive read out the requested 50 
frame block; a transmission stand-by buffer for holding the 
frame blocks read out from the K disk drives; and a firame 
block transmission unit for retrieving the frame blocks from 
the transmission stand-by buffer to transmit to the request- 
sender subscriber interface. 65 

The frame block transmission unit may include: a readout 
request storage unit for storing a readout request for which 
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a requested frame block has been read out and stored in the 
transmission stand-by buffer together with a correlation with 
the frame block; a frame block retrieval unit for retrieving 
the frame blocks from the transmission stand-by buffer; a 
request-sender detection unit for detecting a request-sender 
subscriber inter&ce of die readout request for the frame 
block retrieved from the transmission stand-by buffer; a 
frame block division unit for dividing the retrieved firame 
block from the transmission stand-by buffer into a set of 
sub-blocks of an equal size; a writing unit for writing each 
sub-block into the data area of the cell structure, and writing 
the request-sender detected by the request-sender detection 
unit into the header area of the cell structure; and a cell 
u^mission unit for transmitting the cells written with the 
sub-block and the request-sender subscriber interface to the 
request-sender subscriber interface. 

According to the above construction, upon receipt of a 
video request, the data of the requested video are readout per 
frame block firom a plurality of frame block servers in a 
predetermined sequence and transmitted to the request- 
sender terminal, and thus enabling real time video transmis- 
sion. 

When there are a plurality of requests to one video, each 
frame block server reads out the frame blocks independently 
and sends the sanie to each terminal simultaneously. Thus, 
a plurality of subscribers can access to one video at one same 
time. 

Further, since the ATM switch operates asynchronously 
which each image memory and readout out unit, the number 
of the subscribers and the kinds of videos can be changed 
relatively easy in the interactive system. 

The second object can be fulfilled by a video server which 
transmits digital video data stored therdn to subscriber 
terminals as per video request and which can rewrite the 
digital video data comprismg: a plurality of firame block 
servers, each including an image memory, a readout control 
unit for the image memory, and a writing control unit for the 
image memory, each image memory storing a plurality of 
frame blocks, each firame block being one of sections 
forming a piece of digital video data, the read control unit 
receiving readout requests and in response reading out 
requested frame blocks from the adequate image memory, 
the write control unit receiving a write request and in 
response writing the frame blocks into the image memory; 
a management unit for storing management data specifying 
which frame block server stores which frame block in the 
image memory and which frame block server has a writable 
area in the image memory, and for updating the management 
data each time a firame block is written in the image 
memory; a plurality of subscriber interfaces for receiving the 
video requests torn the subscriber terminals, and in 
response sending readout requests to frame block servers to 
readout frame blocks forming requested digital image data 
in a predetermined sequence while referring to the manage- 
ment data, and for transmitting the frame blocks transmitted 
from the firame block servers to the subscriber terminals at 
such timing that ensures continuous video-play; a write 
interface for obtaining a digital video to divide the digital 
video into a set of sections, and for transmitting the divided 
sections to the frame block servers having the writable areas 
together with the write request, each section being of a same 
size as the firame block; and an exchange uzut for intercon- 
necting each block server, each subscriber interface, and 
each write interface, and for transferring the firame blocks 
read out from the frame block servers and transmitted firom 
the write interfece to tiie request-sender subscriber interfaces 
and the frame block servers having the writable areas 
respectively. 
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The management data may comprise a plurality of block 
pointers, each identifying a location of each frame blodc 
respectively, and including an address of each frame blodc 
server that stores each frame block respectively, and each 
subscriber interface may include: a management data obtain- 5 
ment unit for receiving the video request from the subscriber 
terminal, and in response retrieving block pointers for the 
requested piece of digital video data from the management 
unit; a readout request generation imit for generating a 
readout request fbr each retrieved blodc pomter addressing 
to the frame block server spedfied by the address included 
therein; a readout request transmission unit for transmitting 
the readout requests to the specified frame block servers, one 
readout request being transmitted at a time; and a frame 
block output unit for receiving the &ame blocks read out as 
per the readout requests, and in response outputting the 
frame blocks to the request-sender subscriber terminal at 
predetermined timing. 

Ihe image memory in each frame block server may have 
a memory area which is divided in a set of areas, each area 20 
being suffidendy laige to record one frame block, and the 
management unit may include: a write pointer storage unit 
for storing write pointers, each write pointer being data 
showing a correspondence between the writable area in the 
image memory and its location; a write control data gen- 25 
eration unit for retrieving the write pointers for each frame 
block server from the write pointer storage unit when the 
write mterface receives the write request, and for aligning 
the retrieved write pomters in sequence to generate write 
control data for a piece of digital video data to be recorded; 30 
a management data conversion unit for converting the write 
control data generated by the write control data generation 
unit into the management data, and the write interface may 
include: a management data obtainmem unit for recdving 
the write request, and in response retrieving the write 35 
pointers for the piece of digital video data to be recorded 
from the management unit; and a write request generation 
unit for generating a write request for each retrieved write 
pointer addressing to the frame block server spedfied by the 
write pointer; a division unit for generating a plurality of 40 
frame blocks by dividing the digital video data; a write 
request transmission unit for transmitting the write requests 
first and then the requested frame blocks to the spedfied 
frame block servers, one of one write request and requested 
frame block being transmitted at a time, and wherdn each 45 
specified frame block server writes the frame block on the 
writable area in the image memory spedfied by the write 
request when the write request and the frame block are 
received. 

The exchange unit may be an ATM cell switch for 50 
exchanging cells, and each image memory may be a disk 
array comprising K disk drives for storing the frame blocks, 
and each block pointer may include an address of each frame 
block server storing each frame block, and an address of the 
frame block in the disk array, and each write pointer may 55 
include an address of a frame block server storing the 
corresponding frame block, and an address of the writable 
are in the disk array; the readout request may be of a cell 
strucmre, and the readout request transmission unit writes 
the address of the frame block server in a header area of the 60 
cell structure while writing the address of the frame block in 
the disk array in a data area of the cell structure to generate 
a readout request for each block pointer, and the write 
request transmission unit may write tiie address of the fr^e 
block server in the header area while writing the address of 6S 
the writable area m the data area, iand the readout control unit 
in the frame block server may detect the address of the frame 
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blodc in each readout request and reads out the requested 
frame block by accessmg to the address of the disk array, and 
the write control unit in the frame blodc server may detect 
the address of the frame block in each write request and 
writes the firame block in the writable area 

According to the above construction, the video data can 
be rewritten while being transmitted to their respective 
destination terminals, which makes a variety of videos 
available to the subscribers. 

The third object can be fulfilled by a video server whidi 
transmits digiul video data stored therein to subscriber 
terminals as per video requests comprising: a plurality of 
frame block servers, each including an image memory and 
a readout control unit for the image memory, each image 
memory storing a plurality of frame blodcs, each firame 
block being one of sections forming a piece of digital video 
data, the readout control unit recdving readout requests and 
in response reading out requested frame blocks fix)m the 
image memory; a management unit for storing management 
data specifying which frame block server stores which firame 
block in the image memory; a plurality of subscriber inter- 
faces for recdving the video requests from the subscriber 
terminals, and in response sending readout requests to the 
frame block servers to readout the firame blocks forming 
requested digital image data in a predetermined sequence 
while referring to the management data, and for transmitting 
the frame blocks transmitted firom the frame block servers to 
the subscriber terminals at such timing that ensures a con- 
tiimous play; and an exchange network including a plurality 
of exctmge units interconnected each other, each being 
selectivdy connected to a plurality of frame block servers 
and a plurality of subscriber interfaces for transferring the 
frame blocks addressed to the self s firame block server to 
the request-sender subscriber interfaces respectively. 

The management data may comprise a plurality of block 
pointers, each identifying a location of each firame block 
respectively, and including an address of each firame block 
server that stores each frame block respectively, and each 
subscriber interface may include: a management data obtain- 
mem unit for receiving the video request from the subscriber 
terminal, and in response retrieving block pointers for the 
requested piece of digital video data fipom tiie management 
unit; a readout request generation unit for generating a 
readout request for each retrieved block pointer addressing 
to the fi^e block server spedfied by the address included 
therein; a readout request transmission unit for transmitting 
the readout requests to the spedfied firame block servers, one 
readout request being transmitted at a time; and a frame 
block output unit for recdving the firame blocks read out as 
per the readout requests, and in response outputting the 
frame blocks to the request-sender subscriber terminal at 
predetermined timing. 

The exchange network may be an ATM cell switch for 
transferring the cells, and each image memory may be a disk 
array con^nising K disk drives for storing the frame blocks, 
and each block pointer may include an address of each frame 
block server storing each firame block, and an address of the 
firame block in the disk array, and the readout request may 
be of a cell structure, and the readout request transmission 
unit may write the address of the firame block server in a 
header area of tiie cell stracmre while wiring the address of 
the firame block in the disk array in a data area of the cell 
structure to generate a readout request for each block 
pointer, and the readout control unit in the frame block 
server may detect the address of the firame block in each 
readout request and may read out die requested firame block 
by accessing to the address of the disk array. 
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The disk anay may comprise K disk drives inteicomiected 
by a SCSI, and the address of the frame block may be 
formatted for a readout command in a SCSI system. 

According to the above construction, the frame blocks can 
be transferred between a plurality of the Al^ switches, and 
thus the scale of the video server can be extended. 



BRIEF DESCRIPTION OF THE DRAWINGS 

These and other objects, advantages and features of the 
invention will become apparent from the following descrip- 
tion thereof taken in conjunction with the accompanying 
drawings which illustrate specific embodiments of the 
invention. In the drawings: 

FIG. 1 is a logical format of video data supplied by a 
video server of the present mvention; 

FIG. 2 is a view depicting the structure of a video server 
in accordance with a first embodiment of the present inven- 
tion; 

FIG. 3 is a view explaining how each MSFS (Media 
Segment File Server) stores MSFs (Media Segment Files); 

FIG. 4 is a view showing a logical format of an SCF 
(Sequence Control File) and MSFPs (Media Segment File 
Pointers); 

FIG. 5 is a view depicting the structured of an SM 
(System Manager) shown in FIG. 2; 

FIG. 6 is the control sequence of the video server in 
transmitting the SCFs and MSFPs; 

FIG. 7 is a flowchart detailing the operation of an SCF 
transmission control unit; 

FIG. 8 is a view depicting the structure of an SCB 
(Sequence Control Broker) shown in FIG. 2; 

FIG. 9 is a flowchart detailing the operation of an MSFP 
transmission control unit; 

FIG. 10 is a view depicting the structure of the MSFS 
shown in FIG. 2; 

FIGS. IIA and IIB are the flowcharts detailing the 
operation of an array controller shown in FIG. 10; 

FIG. 12 is a view explaining how the data per sector are 
converted into cells; 

FIG. 13 is a flowchart detailing the operation of a com- 
munication control unit; 

FIG. 14 is a view explaining how a transmission unit 
shown in FIG. 10 transmits the MSFs; 

FIG. 15 is a view depicting the structure of a video server 
installed in a CATV station; 

FIG. 16 is the control sequence of the video server when 
recording the MSFs; 

FIG. 17 is a view depicting the structure of an SCB in 
accordance with a second embodiment of the present inven- 
tion; 

FIG. 18 is a view explaining how a delay management 
unit shown in FIG. 17 manages the delay times; 

FIG. 19 is the control sequence of a video server in 
accordance with the second embodiment; 

FIG. 20 is a view depicting the structure of an MSFS in 
accordance wit a third embodiment of the present invention; 

FIG, 21 is the control sequence of a video server in 
accordance with the third embodiment; 

FIG. 22 is a view depicting the structure of an MSFS in 
accordance with a fourth embodiment of the present inven- 
tion; 
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FIG. 23 is a flowchart detailing the operation of a com- 
munication control unit in accordance with the fourth 
embodiment; 

FIG. 24 is a flowchart detailing the operation of a com- 
munication control unit in accordance with a fifth embodi- 
ment of the present invention; 

FIG. 25 is a view depicting the structure of an ATM switch 
in accordance with the fifth embodiment; 

FIG. 26 is a view explaining how the cells are exchanged 
by the ATM switch in the fifth embodiment; 

FIG, 27 is a view depicting the structure of a network in 
accordance with a sixth embodiment of the present inven- 
tion; 

HG. 28 is a flowchart detailing the operation of a monitor 
control unit shown in FIG. 27; 

FIG. 29 is a flowchart detailing the operation of a monitor 
control unit in accordance with a seventh embodiment of the 
present invention; 

FIG. 30 is a view depicting the structure of an MSFS in 
accordance with an eighth embodiment of the present inven- 
tion; 

FIGS. 31Aand 31B are the views explaining how autho- 
rization is granted; 

HG. 32 is a flowchart detailing the operation of a readout 
unit shown in FIG. 30; 

HG. 33 is a state diagram of a hard disk drive; 

HG. 34 is a flowchart detailing the operation of a queue 
length management unit shown in FIG. 30; 

HG. 35 is a flowchart detailing the operation of a selec- 
tion specification unit shown in HG. 30; 

HG. 36 is a view showing a major part of an MSFS in 
accordance with a ninth embodiment of the present inven- 
tion; 

HG. 37 is a flowchart detailing the operation of a readout 
unit in accordance with the ninth embodiment; 

HG. 38 is a flowchart detailing the operation of a queue 
length management unit in accordance with the ninth 
embodiment; 

HG. 39 is a flowchart detailing the operation of a selec- 
tion specification unit in accordance with the ninth embodi- 
ment; 

HG. 40 is a data fora:iat of a second data request in 
accordance with a tenth embodiment of the present inven- 
tion; 

HG. 41 is a view depicting the structure of an SCB in 
accordance with the tenth embodiment; 

HG. 42 is a view depicting the structure of an MSFS in 
accordance with the tenth embodiment; 

HG. 43 is a flowchart detailing the operation of a second- 
data-request receipt unit shown in HG. 41; 

HG. 44 is the data format of a first data request; 

HGS. 45A through 45C are the views explaining how 
issuance is scheduled by an issiiance time management unit 
shown in HG. 41; 

HG, 46 is a flowchart detailing the operation of the 
issuance time management unit; 

HG. 47 is a flowchart detailing the operation of a first- 
data-request transmission judgment unit; 

HG. 48 is a flowchart detailing the operation of a first- 
data-request transmission unit; 

HGS. 49A and 49B are the timin g charts of the issuance 
of the first and second data requests; 
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FIG. 50 is a flowchart detailing the operation of an MSF 
distribution unit; 

FIO* 51 is a flowchart detailing the operation of a first- 
data-request receipt unit; 

FIG. 52 is a flowchart detailing the operation of a data 
readout transmission control unit; 

FIG. 53 is a flowchart detailing the operation of a data 
transmission unit; 

FIG. 54 is a view depicting the structure of a copy unit in 
accordance with an eleventh embodiment of the present 
invention; 

FIG. 55 is a flowchart detailing the operation of an array 
controller m accordance with the eleventh embodiment; 

FIG. 56 is a view showing an example of an MSF 
transmission management table in accordance with a twelfth 
embodiment of the present invention; 

FIG. 57 is a flowchart detailing the process upon receipt 
of a readout request in the twelfth embodiment; 

FIG. 58 is a flowchart detailing the MSF transmission 
process in the twelfth embodiment; 

HG. 59 is a flowchart detailing the operation of an SCF 
obtaiiunent control unit in accordance with a thirteenth 
embodiment of the present invention; 

FIG. 60 is a view depicting the structure of an SM in 
accordance with a fourteenth embodiment of the present 
invention; 

FIG. 61 is a view depicting the structure of an MSFS in 
accordance with the fourteenth embodiment; and 

FIG. 62 is a flowchart detailing the operation of a com- 
munication control unit in accordance with the fourteenth 
embodiment 

DESCRIPTION OF THE PREFERRED 
EMBODIMENTS ' 

First Embodiment 
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The format of the digital video data supplied by a video 
server 100 in accordance with the first embodiment of the 
present invention is shown in HG. 1. The digital video data 
are compressed by, for example, the MPEG (Motion Pic- 
tures Expert Group) 2 method, and divided into a set of 64 
Kbyte files; hereinafter the resulting files are referred to as 
MSFs (Media Segment Files) which are numbered with their 
respective sequence numbers in one program as shown in 

HG. 1: (MSF){1), MSF(2), MSF(3), MSF(4) For 

example, a 10-minute long MPEG 2 video with a transmis- 
sion rate of 6.4 Mbps (bit per second) is divided into 7500 
MSFs. 

FIG. 2 is a block diagram showing the structure of the 
video server 100. Tht video server 100 comprises a plurality 
of MSFSs (Media Segment File Serves) 1000, 1001, 1002, 
1003 . . . , an SM (System Manager) 2000, a plurality of 
SCBs (Sequence Control Brokers) 3000, 3001, 3002, 3003, 
. . . , an ATM switch 4000. and an FD (Ffle Distributor) 5000. 

Each MSFS includes a SCSI (Small Computer System 
Interface) disk array for storing a plurality of MSFs and ^ 
transmits the same. How each MSFS stores the MSFs will 
be explained while referring to FIG; 3. 

In the drawing, each rectangle represents one MSFS while 
squares within each rectangle representing the MSFs stored 
therein, and the MSFs forming one program are stored 
separately in the MSFSs. Assume that there is 1000 MSFSs, 
PROGRAM 1 consists of 2000 MSFs and each of PRO- 
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GRAMS 2 and 3 consists of 1000 MSFs, then the MSF(1) 
of PROGRAM 1 is stored in the MSFS 1000, (MSF(2) in the 

MSFS 1001, MSF(3) in the MSFS 1002 MSF(1000) 

in the MSFS 1999, MSF(1001) in the MSFS 1000, 
MSF(1002) in the MSFS 1001, MSF(1003) in the MSFS 
1002. . . . , and MSF(2000) in the MSFS 1999. Similariy, the 
MSF(1) of PROGRAM 2 is stored in the MSFS 1000, 
MSF(2) in the MSFS 1001, . . . , and MSF(IOOO) in the 
MSFS 1999; the MSF(l) of PROGRAM 3 is stored in the 
MSFS 1000, MSF(2) in the MSFS 1001. .... and 
MSFdOOO) in the MSFS 1999. 

If a 10-minute long MPEG2 video consisting of 7500 
MSFs are stored in 100 MSFSs, 75 MSFs are stared in each 
MSFS. 

Each MSFS transmits the MSFs thus stored to the ATM 
switch 4000 as per readout requests send £nom the SCBs 

3000, 3001, 3002, 3003 ... by means of the ATM switch 
4000. 

The SM 2000 stores SCPs (Sequential Control Files) for 
each program and transmits the same: when the SM 20(N) 
receives an SCF obtaiiunent request from the SCBs 3000, 

3001, 3002, .... it transmits the requested SCF to the 
request-sender SCB by means of the ATM switch 4000. The 
SCF is the data used to convert the MSFs stored separately 
in the MSFSs into the video data of one program, and 
consists of MSFPs (Media Segment File Pointers) that 
indicate which MSF is stored in which MSFS. Examples of 
the SCF and MSFPs are shown in FIG. 4. The MSFPs are 
aligned according to the sequence of the corresponding 
MSFs, and each MSFP consists of data related to the MSFS 
storing the MSF, a sequence number at which the MSF is 
read out or written in, and a command assigned to the MSFR 
The MSFS data consist of an MSFS's address (the one 
managed by the AIM switch 4000). a number specifying an 
SCSI of a disk storing the MSF (4 bits), a number specifying 
the disk (4 bits), and a number spedfying a logical block 
indicating the MSF*s storage location (20 bits). The com- 
mand specifies which disk control conunand is assigned to 
the MSFP, and a "read" command is assigned in general. 
Thus, since each MSFP includes parameters of the read 
command for the disk array, it also serves as a disk control 
command to read out the data by accessing to the disk array. 

The SCBs 3000, 3001, 3002, 3003, ... are equipped on 
subscriber lines connecting the ATM switch 4000 and ter- 
minals installed at each subscriber's end, and responsible for 
the program request transmission, MSFP transmission, and 
MSF recepdon defined as follows. 

The program request transmission by the SCBs means to 
have the SM 2000 transmit the SCF including the MSFPs for 
a selection request sent from the terminal by retrieving the 
data related to the program from the selection request 

The MSFP transmission by the SCBs means to have the 
MSFSs 1000, 1001, 1002, . . . transmit the MSFs specified 
by the MSFPs in the SCF transmitted from the SM 2000 by 
generating readout requests using the MSFPs and transmit- 
ting the same by means of the Al^ switch 4000. 

The MSF reception by the SCBs means to receive the 
MSFs successively transmitted from the MSFSs 1000, 1001, 
1002, ... by means of the ATM switch 4000 and align the 
same sequentially to output the same to the terminal as the 
original digital video data. 

The ATM switch 4000 is an ATM switch that exchanges 
cells asynchronously, and all the readout request, SCF 
obtainment requests, SCFs and MSFs are converted into the 
cells to be transmitted by the ATM switch 4000. The cells 
referred herein are the data consisting of a S-byte header area 



5,610,841 



11 



12 



and 48-byte data area. The header area includes a destination 
address and an area used to dieck the validity of the 
destination address. The AIM switch is explained in "Infor- 
mation Processing", Vol. 33, No. 2, Februaiy 1992, and 
further explanation is omitted herein. The destination 
addresses referred herein are the addresses of the SCBs 
3000, 3001, 3002. 3003, . . . , MSFSs 1000, 1001, 1002, 
1003, 1004, .... and SM 2000, and each cell travels within 
the video server 100 using these addresses. 

The FD 5000 receives a digital-video signal in the form of 
the digital codes, and divides the same into a set of MSFs to 
write into the MSFS 1000, 1001, 1002, . . . separately. 

The terminal, to which the video sis supplied, comprises 
a display for showing a video transmitted from the video 
server 100, a video selection panel enabling the subscriber 
to select a video, a playback mode selection panel enabling 
the subscriber to select a playback mode, and an output unit 
outputdng a selection signal containing data related to the 
selected video and playback mode. 

The structure of the SM 2000 is depicted in FIG. 5. The 
SM 2000 comprises an SCF storage unit 10, an SCF 
transmission control unit 11, a charge management unit 13, 
and a load judgment unit 14. 

More precisely, the SCF storage imit 10 stores the SCFs 
for each program in relation with their respective transmis- 
sion rates. The transmission rate is directly proportional to 
the quality of the programs transmitted by the video server 
100. For example, the transmission rate is set at 6.0 Mbps for 
a high quality program, and 1.5 Mbps for a relatively low 
quality program. 

THE SCF transmission control unit 11 controls the trans- 
mission of the SCFs, which will be explained while referred 
to FIGS. 6 and 7. FIG. 6 is the sequence showing the video 
data readout operation within the video server 100, and FIG. 
7 is a flowchart detailing the operation of the SCF trans- 
mission control unit II. Assume that a subscriber selects a 
soccer news by means of his terminal, then a selection signal 
(Siart_ Video) is inputted into one of the SCBs (herein 
3000) from the terminal. Accordingly, the SCB 3000 sends 
an SCF obtainment request (SCF__Get_Jteq) to the SCF 
transmission control unit 11 by means of the ATM switch 
4000. Upon receipt of the SCF obtainment request (SCF_ 
Gei_Req) (SlOl), the SCF transmission control unit 11 
retrieves the SCF corresponding to the soccer news from the 
SCF storage unit 10 (S102) and transmits the same (SCF„ 
Get_J^) to the request-sender SCB 3000 (S103). 

The charge management unit 13 retrieves the SCF speci- 
fied by the SCF obtaiimient request from the SCF storage 
unit 10 to detect the size thereof when the SCF transmission 
control unit 11 receives the SCF obtairunent request, and sets 
the charges based on the detected size. By setting the charges 
depending on the SCF sizes, the charges become directly 
proportional to the video length. 

The load judgment imit 14 determines whether the SCF 
obtairunent request received by the SCF transmission con- 
trol unit 11 should be accepted or rejected. Such judgment 
is made based on each program's transmission rate stored in 
the SCF storage unit 10 and the trafiEc within the ATM 
switch 4000. In case of rejection, the load judgment unit 14 
transmits a notice of rejection to the SCF transmission 
control unit 11, which in return transmits the notice of 
rejection to the SCF-obtainment request-sender terminal via 
the SCB 3000 instead of the respoiise (SCF_Get_Rsp). 

The SCBs 3000, 3001, 3002, ... are of the same strucmre, 
and the SCB 3000 will be explained as an example while 
referring to FIG. 8 depicting the structure thereof. 
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The SCB 3000 comprises a selecdon signal separation 
unit 20, a buffer memory 21, a buffer memory monitor unit 
22, and an MSFS transmission control unit 23. 

More precisely, the selection signal separation unit 20 
separates the selection signal sent &om the tominal via a 
subscriber line 1 (SLl): upon receipt of the selection signal, 
it separates the same into a program request and a playback 
mode request; die former is transmitted to the SM 2(NM) by 
means of die ATM switch 4000 via a subscriber line 2 (SL2), 
and die latter to the MSFP transmission control unit 23 via 
a subscriber line 4 (SL4). The playback mode referred herein 
includes norriial, fast, reverse, firame-by-framc, skip, still, 
and location-specifying modes. 

The buffer memory 21 is a memory temporarily holding 
a predetermined length of MSFs successively transmitted 
&om die MSFSs 1000, 1001, 1002, ... via a data line 2 
(DL2) by means of the ATM switch 4000. The buffer 
memory 21 outputs the MSFs to the terminal synchronously 
with a predetermined block signal via a data line 3 (DL3). 
The cycle of the clock signal is determined depending on the 
video length for one MSF. Assume that 1 -second long video 
consists of 30 frames and one MSF corresponds to 10 
frames, then the buffer memory 21 transmits one MSF every 
Yi second to the terminal. 

The buffer memory monitor 22 monitors an available 
edacity of the buffer memory 21. 

Hie MSFP transmission control unit 23 includes an SCF 
buffer (not shown) withholding the SCFs transmitted from 
the SM 2000, and controls the above-defined MSFP trans- 
mission. Hie operation of the MSFP transmission control 
unit 23 will be explained while referring to FIG. 6 and the 
flowchart in FIG. 9. 

The MSFP transmission control unit 23 receives the 
playback mode request from the selection signal separation 
unit 20 and die SCF from the SM 2000 by means of the ATM 
switch 4000, and stores the SCF into die SCF buffCT (S201). 
Subsequentiy, the MSFP transmission control unit 23 out- 
puts a ready signal to the terminal and judges the selected 
playback mode (S202). Assuming that the normal mode has 
been selected, tiien the MSFP transmission control unit 23 
detomines to transmit the readout requests as per SCF 
(S203). Having detemuned the transmission sequence, the 
MSFP transmission control unit 23 ou^uts a start request 
Cnt^Start^eq) to die SM 2000, and waits for a response 
Cnt_ Start_Rsp). Upon receipt of the response and SCF, die 
MSFP transmission control urut 23 generates readout 
requests for die requested video using die MSHPs in die 
SFC; the readout requests are in effect the cells storing the 
parameters of the MSFPs to convey the MSFPs to die 
MSFSs. In HG. 6, (MSF_Read_Rcq(l)) is die first readout 
request addressed to diie MSFS 1000 (MSFS[1]), and MSF 
Read_Req(2)) and (MFS_Kead_Req(3)) are die second 
and third readout requests addressed to the MSFS 1001 
(MSFS[2]) and die MSFS 1002 (MSFS[3]) respectively. 

Having generated the readout requests for the video, die 
MSFP transmission control unit 23 transmits the same to 
their respective MSFSs successively. For example, the 
MSFP transmission control unit 23 transmits die first readout 
request (MFS_Read_Jleq(l)) to die MSFS 1000 at a pre- 
determined interval before the buffer memory 21 transmits 
die MSF[1] (S204. S205, S206), and transmits die following 
readout request (MSF_Read_Req(2)) and (MSF_Read_ 
Req(3)) at die predetermined interval before the buffer 
memory 21 transmits die MSF[2] and MSF0] respectively 
S204, S205, S206). The predetermined interval referred 
herein is an estimated interval between the time when each 
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readout request is transmitted and the receipt of the coxxe- 
spending MSF. and it is calculated using the MSFS's MSF 
readout rate, AIM switch 4000's exchange ability, and the 
bu£fer memory 21* s MSF transmission rate. 

The MSFS 1000 reads out the MSF(1) as per the fii^t s 
readout request (MSF_Rcad_jlcq(l)) upon receipt thereof, 
and sends the same to the MSFP transmission control unit 23 
as a response (MSF_Read_Rsp(l)). Hie MSF(1) thus read- 
out is stored in the buffer memory 21 after some interval 
(Delay Time (1)) has passed. 

Similarly, the responses (MSF_J^ead_Rsp(2)) and 
(MSF_Read_Rsp(3)) are successively transmitted to the 
MSFP transmission control unit 23 from the MSFS 1001 and 
MSFS 1002 after some intervals. (Delay Hme (2)) and 
(Delay Time (3)) respectively, and the MSFP transmission ^ 
control unit 23 stores the same into the buffer memory 21. 
The MSFs stored in the buffer memory 21 are successively 
transmitted to the terminal, which accordingly converts the 
MSFs into consecutive video data (^deo_Data(l) and 
Video_Data (2)) first and tbca decodes the same while 
counting the number of the frames of the video data, playing ^ 
the requested video. 

While the memory buffer 21 stores the MSFs, the MSFP 
transmission control unit 23 periodically inquires the buffer 
memory monitor unit 22 whether there is an available 
capacity in the buffer memory 21. The MSFP transmission ^ 
control unit 23 does so because the buffer memory 21 must 
have an. available capacity to store the MSFs successively 
read out from the MSFSs as per readout requests: when the 
buffer memory 21 has an overflow or underflow within the 
predetermined interval, the MSFP transmission control unit 30 
23 adjusts the timing of the readout request transmission. 

When a pause request is inputted from the terminal, the 
pause request is transmitted to the MSFP transmission 
control unit 23 by means of the selection signal separation 
unit 20. The MSFP transmission control unit 23 accordingly 35 
has the buffer memory 21 suspend the MSF transmission to 
the terminal. 

When resuming the video play, a resume request is 
transmitted to the MSFP transmission control unit 23 from 
. the terminal with a number representing the frame from 40 
which the video-pay is resumed. 

When the reverse mode is selected, the MSFP transmis- 
sion control unit 23 arranges the sequence of the MSFPs in 
a maimer reversed to the sequence iii the SFC and deter- 
mines the same as the readout request transmission 
sequence, for example, MSFP 1200-MSFP 1195>-MSFP 
U98^SFP 1197. 

When the skip mode is selected, the MSFP transmission 
control unit 23 arranges the sequence of the MSFPs by 
skipping a predetermined number of the MSFPs to deter- ^ 
mine the same as the readout request transmission sequence, 
for example, MSFP 1-MSFP 60-MSFP m-MSFP 180. 

Wh^ the location-spedlying playback mode is selected, 
the MSFP transmission control unit 23 arranges the 
sequence of the MSFPs starting from an MSFP specified by 
the subscriber to determine the same as the readout request 
transmission sequence, for example, MSFP 301-MSFP 
302-MSFP 303-MSFP 304. 

While controlling the MSFP transmission, the MSFP ^ 
transmission control unit 23 checks the last MSFP in the 
SCF by referring to the sequence number of the MSFSs in 
the readout requests, and once the MSFP transmission 
control unit 23 has transmiued the last readout request 
(S206). it waits for the following SFC (S201). ^5 

The MSFSs 1000, 1001, 1002, 1003. ... are of the same 
structure, and the MSFS 1000 will be explained as an 
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example while referring to FIG. 10 depicting the structure 
thereof. The MSFS 1000 comprises a request recdpt unit 31, 
first through K'th queues 41 ... 4K, a SCSI disk array 50 
including first through K*th hard disk drives 51 . . . 5K, an 
array controller 60, a transmission stand-by buffer 62, a 
readout delay timer 64, a transmission unit 61, and a 
communication control unit 65. 

The request receipt unit 31 receives the readout requests 
successively transmitted from the SCBs by means of the 
ATM switch 4000. 

The queues 41 ... 4K are frimished for the hard disk 
drives 51 . . . 5K respectively, and each accumulates the 
readout requests for the respective hard disk drives. 

The disk array 50 indudes the hard disk drives 51 . . . 5K 
which are interconnected each oth^ by a SCSI and operate 
in parallel. Each hard disk drive comprises a disk whose 
memory is divided into a set of sectors each storing the 
1024-byte data forming the MSF, a disk driving system, and 
a head for reading out the data in the sectors, and a seek 
system for seeking the head. Each hard disk drive reads out 
the data in the sectors by controlling the disk driving system 
and seek driving systera For this reason, not all the d^ are 
read out at the same readout rate: the readout rate is directly 
proportional to the distances between the head and the 
sectors. The disks in the hard disk drives 51 . . . 5K operate 
in parallel, and thus the hard disk drives 51 . . . 5K operate 
as if they were one unit by driving the disks alternately or 
sequentially. Note that one of the hard disk drives is exclu- 
sively used for code correction to ensure the reliability. 

The array controller 60 controls the disk array 50 and 
MSF transmission. The operation of the array controller 60 
will be explained while referring to the flowcharts in FIGS. 
IIA and IIB. In the drawmg, Kdisk is a variable equal to 2 
or more (k^2) that specifies the queues furnished for each 
hard disk drive and its disk in the disk array 50. 

When the request receipt unit 31 receives the readout 
request (MSF_Jlead_Req) (S301), the array controller 60 
analyses the same to specify the disk that contains the 
requested MSF. Assume that the requested MSF is stored in 
the k'th hard disk drive Sk, the array controller 60 stores the 
readout request into the corresponding k'th queue 4k (S302). 
When the k'th queue 4k receives the readout request (S303), 
the array controller 60 retrieves the readout request in the 
k'th queue (S304) to readout the MSF per sector (S305). 
When the readout operation completes (S306), the array 
controller 60 increments the queue number by one (S307). 

The transmission unit 61 converts the MSFs read out from 
the disk array 50 per sector into a set of cells and outputs the 
same to the ATM switch 4000, which wiU be explained more 
in detail while referring to FIG. 12. 

The transmission unit 61 attaches 24-byte ID data and 
8-byte trailer to 1024-byte data of one sector, makiiig 
lQ56-byte data, divides the resulting 1056-byte data into a 
sa of 48-bytB data areas, and attaches a 5-byte header area 
to each generating 22 ceUs as a result Having generated the 
cells, the transmission data 61 detects the SCB that has sent 
the readout request and stores the address thereof into the 
header area. 

Because one MSF has a file size of 64 Kbytes, 64x22 
(1048) cells are generated from one MSF, which are sepa- 
rately transmitted to the SCBs 3000, 3001, .... Since die 
transmission unit 61 carries out the above MSF-to-Cell 
conversion process 64x22 (1408) times to transmit one 
MSF, the MSFs read out from the disk array 50 are not 
transmitted instantaneously. 

Also, the transmission unit 61 inquires whether the ATM 
switch 4000 has an overflow, and in case of overflow, to 
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suspend the cell transmission until the overflow is elimi- 
nated 

TTie transmission stand-by buffer 62 is a FIFO (first-in- 
first-out) memoiy to withhold the M SFs read out fh)m the 
disk array 50 to deliver the same to the transmission unit 61 5 
in the readout sequence; for the readout MSFs are not 
transmitted instantaneously. 

The readout delay timer 64 mdudes a plurality of 
counters that operate in parallel, and sets a timing to deliver 
the MSFs in the transmission stand-by buffer 62 to the 
transmission unit 61. 

The communication control unit 65 controls the MSF 
transmission by the MSFS 1000, ^ch will be explained 
while referring to the flowchart in FIG. 13. 

The communication control unit 65 monitors the receipt 
of a readout request by the request receipt unit 31, and the 
con^)letion of the MSF transmission by the transmission 
unit 61 (CIO. Cll). Upon detection of tht readout request 
receipt in CIO, the communication control unit 65 activates ^ 
the readout delay timer 64 to count the dme for the readout 
request (C12), and has the array controller 60 accumulate the 
readout request in the corresponding queue (C13). When the 
transmission unit 61 completes the transmission of one MSF 
in Cll, the communication control unit 65 checks whether ^5 
there is any MSF in the transmission stand-by buffer 62 
(C14) to further check whether the time-out has come for the 
first-in MSF thereia (C15). When the time-out has come, 
the oonmiunication control unit 65 has the transmission 
stand-by buffer 62 deliver the first-in MSF to the transmis- 
sion unit 61 (C16), which accordingly transmits the same to 
the ATM switch 4000. 

HG. 14 details the timing control by the readout delay 
timer 64 described using the flowchart in FIG. 13. When the 
request receipt unit 31 receives a readout request 3a at the 35 
timing of 3al (CIO), the readout delay timer 64 start to count 
the time for the readout request 3a. Accordingly, the MSF3a 
is read out from the disk array 50 as per the readout request 
3a and stored in the transmission stand-by buffer 62 at the 
timing of 3a2. Although it becomes possible for the trans- 40 
mission stand-by buffer 62 to transmit the MSF3a at the 
timing of 3a3 (Cll), the MSF3a is not delivered to the 
transmission unit 61 untO the readout delay timer 64 counts 
the time-out 3T. When the readout delay timer 64 counts 3T 
(3a4), the communication control unit 65 has the transmis- 45 
sion stand-by buffer 62 deliver the MSF3a to the transmis- 
sion unit 61 (C16). 

Similarly, when the request receipt unit 31 receives read- 
out request 3^ and 3c at the timing of 3bl and 3cl respec- 
tively (CIO), the readout delay timer 64 starts to count the so 
time for each request Hien, the MSF3fr is readout from the 
disk array 50 as per the readout request 3b and stored in the 
transmission stand-by buffer 62 at the timing of 3b2, Sub- 
sequently, the MSF3c is readout from the disk array 50 as 
per the read request 3c and stored in the transmission S5 
stand-by buffer 62 at the timing of 3c2. Note that the 
MSF3a, MSF3^ and MSF3c are readout at the different 
timing because the time required to read out the MSFs varies 
depending on where they are stored in the disks. Although 
it becomes possible for the transmission stand-by buffer 62 60 
to deliver the MSF3f> and MSF3c at the timing of 3b3 and 
3c3 respectively (Cll), neitiier the MSF3b nor MSF3c is 
delivered until the readout delay timer 64 counts 3T for each. 
When the readout delay timer 64 counts 3T for each {3b4 
and 3c4), the communication control unit 65 has the trans- 65 
mission stand-by buffer 62 deliver the MSF36 and MSF3c to 
the transmission unit 61 (C16). 



Due to the above timing control by the readout delay timer 
64, the MSFs are delivered to the transmission unit 61 at 
regular intervals from the receipt of their respective readout 
requests even when the MSFs are readout at different timing. 

Following is the explanation of how the scale of an 
interactive system employing the above video server 100 
will be determined. 

First, the number of the subscribers (NSB) of the inter- 
active system must satisfy Equation (1) as follows: 



NSB<EX/(pxrt) 



(1) 



where 

EX is the AM switch 4000's exchange ability; 

rt is a transmission rate per video of the subscriber line 
connecting the SCBs and terminals; 

p is the usage finequency per subscriber (times/second). 

Now, let HX be 2.4 Gbps, rt be 1.5 Mbps, and p be O.OS, 
then we get NSBO2000. 

Hius, the interactive television system eii^)loying the 
video server 100 can provide the service to approximately 
32000 subscribers. 

Then, die number of the MSFSs (NDB) is found by 
Equation (2) as follows: 



NDB>EX/rr 



(2) 



where 

rr is the MSFS*s maximum retrieval rate. 

Let rr be 12 Mbps, then we get NDB>200, which means 
the video server 100 must be furnished with 201 or more 
MSFSs. 

Further, the number of subscribers (NACC) that can 
access to the video server 100 simultaneously is found by 
Equation (3) as follows: 



NACC=NDBxirT/rt) 



(3) 



Hius, we get NACC^1600. 

Also, the disk array 50 within each MSFS demands a 
capacity (DBxNB) calculated by Equation (4) as follows: 



iDBxNBpSnotTXTt/HDB 



(4) 



where 

DB is the file size of one MSF; 
NB is the maximum number of MSFs stored in one 
MSFS; 

Sm is the number of the videos; and 

T is the length of one video in time unit 

Let T be 3 minutes and Sm be 3000. tixen we get 
(DBxNB)=approximately 5 GB. 

Further, a capacity (B) of the buiffer memory 21 is found 
by Equation (5) as follows: 



B>fr (rr-rt)={l-<rt^)}X>fi 



(5) 



tr(=DB/rr) is the time required to transmit one MSF from 

the MSFS to the SCB; and 
tt(=DB/rt) is the time required to transmit one MSF from 

die SCB to the terminal. 
For the interactive system constmcted as above, PC/AT 
compatible personal computers installing an ATM interface 
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card for the cell transmission and an i486DX-2-66 CPU 
(Intel Corp.) can be used as the MSFS 1000, 1001, 1002, . 
. . . SM 2000. SCBs 3000, 3001, 3002. .... 

According to the first embodiment, when a video is 
requested &om tiie subscnber, the MSFs forming the 5 
requested video are read out from a plurality of MSFSs in a 
piedetennined sequence and successively transmitted to the 
request-sender subscriber via the subscriber line, making the 
read time access possible without having the subscriber kept 
waiting. lO 

Also, by transmitting the MSFs consecutively at regular 
intervals even when the MSFs are read out at different 
timing, the video is transmitted continuously. 

In this embodiment, the SCF stores the readout sequence 
of all the MSFs in one program; however, it may store only is 
the MSFS's address of the first MSF of the program and its 
sequence number tar have each hard disk drive store the 
addresses of the following MSFs (such as the address of the 
MSFS 1000). In this case, when the first MSF is read out, a 
chain of the following MSFs is read out That is to say, each 20 
time one MSF is read out from the corresponding hard disk 
drive, the MSFP transmission control unit 23 receives the 
address of the following MSF and sends the readout request 
to the corresponding hard disk drive. 

Also, the MSFP transmission control unit 23 sends the 25 
readout requests for the second and onwards MSFs sequen- 
tially at the predetermined interval before the buffer memory 
21 transmits the corresponding MSF in the first embodi- 
ment. However, the MSFP transmission control unit 23 may 
transmit the same each time an adequate capacity becomes 30 
available in the buffer memory 21 or when most of the MSFs 
in the buffer memory 21 have been transmitted using the 
buffer memory monitor unit 22. 

The MSFSs, SM and SCBs are not necessarily provided 
separately, the MSFS and SCB may be one unit 35 

The MSFs may be transmitted at irregular intervals to the 
tCTiinals in the form of packets. 

Second Embodiment 

40 

In the second embodiment, each SCB counts the delay 
time between the transmission of the readout request and the 
receipt'of the requested MSF, and exploits the delay time for 
the following readout request transmission. Hius, each SCB 
in the second embodiment additionally includes a delay 
management unit 24 as shown in FIG. 17. 

The delay management unit 24 counts the time between 
the transmission of the readout request and the receipt of the 
requested MSF as a delay time, and manages the delay times 
in relation with the individual MSFSs as delay data. An 50 
example of the delay data is shown in FIG. 18, and the delay 
management unit 24 manages the delay times for the readout 
request to MSFS 1000, MSFS 1001, and MSFS 1002 
separately. Further, the delay managemerU unit 24 directs the 
MSFP transmission control unit 23 to transmit the readout 55 
requests based on the delay data. 

FIG. 19 shows an example of a control sequence of the 
MSFP transmission control unit 23 and MSFSs 1000, 1001. 

1002, In the drawing, (la, AlOl) is a readout request 

addressed to the MSFS 1000 to read out MSF(AIOI). 60 
Similady, (lb, A102) is a readout request addressed to the 
MSFS 1001 to read out the MSF(A102), and (Ic, A103) is 
a readout request addressed to the MSFS 1002 to readout the 
MSF(A103). The control sequence shows that the MSFP 
transmission control unit 23 transmits these readout requests 65 
to the corresponding MSFSs 1000, 1001. 1002 and the 
buffer memory 21 receives the requested MSFs (AlOl). 
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(A102), and (A103) after the delay management unit 24 has 
counted the delay times Da. Db. and Dc, respectively. 
Accordingly, the delay management unit 24 subtracts the 
predetermined interval explained in the first embodiment 
firom the delay times and notifies the balance to the MSFP 
transmission control mdt 23. By so doing, in case of FIG. 19, 
the delay management unit 24 have the MSFP transmission 
control imit 23 transmit a readout request (lOo. AllO) 
addressed to the MSFS 1009 (not shown) to readout the 
MSF(A110) at an interval corresponding to the balance 
before the predetermined interval. By managing the delay 
time for each MSFS and transmitting ^e readout requests 1^ 
taking the delay time into account, the requested MSFs are 
received at regular intervals even when they are transmitted 
at different timing. 

In the second embodiment, the delay times are managed 
in relation with the individual MSFSs; however, the delay 
time for the latest readout request to the same MSFS may be 
used instead. In this case, the latest delay time is compared 
with the delay time in the delay data, and when the two 
values do not coincide, the latter is updated by the former. 



Third Embodiment 

In the third embodiment, each MSFS estimates the delay 
time depending on the numbo' of the accumulated readout 
requests, and notifies the estimated delay time to the SCB 
(herein 3000) that has sent the readout request besides the 
effects realized by the second embodiment 

Thus, as shown in HG. 20, the MSFS 1000 in the third 
embodiment includes a delay data transmission unit S6 
instead of the readout delay timer 64 to notify the estimated 
delay time value to the SCB 3000. 

The delay data transmission unit 66 estimates the time 
required to complete a readout request received by the 
request receipt unit 31 depending on the number of the 
readout requests accumulated in the corresponding queue. 
When the estimated time exceeds a predetermined value, the 
delay data transmission unit 66 converts the estimated value 
into the cells, and transmits the same to the delay manage- 
ment unit 24 in the SCB 3000 as a delay notice. Having 
received the delay notice, the delay management unit 24 
manages the estimated time in the delay notice as the delay 
time for the MSFS 1000. 

The operation of the delay data transmission unit 66 will 
be explained while referring to FIG. 21 showing an example 
of a control sequence of the MSFP transmission control unit 

23 and MSFSs 1000, 1001. 1002 In the drawing, (la, 

AlOl) is a readout request addressed to the MSFS 1000 to 
readout MSF(A101). Similarly, (1^ A102) is a readout 
request addressed to the MSFS 1001 to readout MSF(A102) 
and (Ic, A103) is a readout request addressed to the MSFS 
1002 to readout MSF(A103). 

Assume that the readout request (Ic, A103) received by 
MSFS 1002 is accumulated in fiie corresponding queue, then 
the delay data transmission unit 66 estimates the delay time 
for the readout request (Ic, A103) by taking into account the 
queue length (the number of the readout request accumu- 
lated in the queue), and returns the estimated delay time Dc' 
as the delay notice to the delay management unit 24 in the 
SCB 3000! Hien. the delay management unit 24 directs the 
MSFP transmission control unit 23 to transmit the following 
readout request by taking into account the delay time Dc'. 

By managing the estimated delay time for each MSFS and 
sending the readout requests by takmg the estimated delay 
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time into account, the MSFs are received at regular intervals 
when the MSFs are transmitted at different timing. 

Fotnth Embodiment 

In the fourth embodiment, eadi SCB counts the time ^ 
between the transmission of the readout request and the 
receipt of the requested MSF, and when the counted time 
exceeds a predetermined time Tdl, the SCB discards the 
received MSF 

To be more eflScient, each MSFS in the fourth embodi- 
mem also discaids the MSFs which are likely to be discarded 
by the SCBs before it transmits such MSFs to the ATM 
switch '4000. 

Hius, each MSFS in the fourth embodiment includes a 15 
transmission delay tim^ 81 instead of the readout delay 
timer 64 and a communication control imit 82 instead of the 
communication control unit 65 as shown in FIG. 22. 

The transmission delay timer 81 is of the same stmcturc 
as the readout delay timer 64; however, it counts a waiting 20 
time for each MSF in the transmission stand-by buffer 62, 
and the maximum waiting time is set as the time-out Tml 
using Equation 6 as below. 

25 

rml=Wl-ral-7W (6) 

wherein 

Tal is the minimum delay time between the transmission 
of the readout request from the SCB 3000 and the 30 
delivery of the requested MSF to the transmission xadi 
61; 

Tbl is the minimum delay time between the transmission 
of the MSF from the transmission unit 61 and the 
receipt of the same at the SCB 3000. 35 

Hie communication control unit 82 controls the commu- 
nication within the MSFS 1000, and whose operation will be 
explained while referring to the flowchart in FIG. 23. Since 
the flowchart is partly identical with the flowchart in FIG. 
13, only the different steps will be explained. 40 

The communication control unit 82 monitors the receipt 
of a readout request at the request receipt unit 31 (CIO), a 
new MSF in the transmission stand-by buffer 62 (C21), the 
completion of the MSF transmission by the transmission 
unit 61 (CU), and time-out MSFs (C23). 45 

When the request receipt unit 31 has not received any 
readout request in CIO, and a new MSF is stored in the 
transmission stand-by buffer 62 in C21, the communication 
control unit 82 activates the transmission delay timer 81 to 
start to count the waiting time for the new MSF (C24). When 50 
the transmission unit 61 has completed the transmission of 
one MSF (C22), the conmounication control unit 82 checks 
whether there is any MSF in the transmission stand-by buffer 
62 (C14) to have the transmission stand-by buffer 62 deliver 
the firsl-in MSF therein 10 the transmission unit 61, while 55 
having the transmission delay timer 81 reset the counting 
value for the delivered MSF (C27). 

When the communication control unit 82 detects the 
time-out MSF in C23. it discards such an MSF {C28) and has 
the transmission delay timer 81 reset the counting value for 60 
the discarded MSF (C28). 

By discarding the MSFs that have been withheld in the 
transmission stand-by buffer 62 for a long time in each 
MSFS, most of the MSFs that are likely to be discarded by 
the SCBs are discarded before they are transmitted to the 65 
ATM switch 4000, and thus reducing the load to the ATM 
switch 4000. 
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The time between the MSF delivery from the transmission 
stand-by buffer 62 and the MSF transmission by the trans- 
mission unit 61 is counted in this embodiment However, the 
time between the receipt of the readout request and the 
transmission of the requested MSF at each MSFS may be 
counted instead. 

Fifth Embodiment 

In the fifth embodiment, priority is given to the cells 
converted finom the MSFs that took a considerably long time 
to be read out 

Thus, the MSFS 1000 in the fifth embodiment is of the 
same structure as the MSFS 1000 in the first embodiment 
except that the conununlcation control unit 65 has the 
transmission unit 61 set a delay level in each cells forming 
the MSFs. 

The communication control unit 65 transmits the cells by 
the transmission unit 61 after the transmission unit 61 has set 
a low delay level to each when the corresponding MSF is 
read out before the time-out, and a high delay level when it 
is readout after the time-out 

The operation of the communication control unit 65 will 
be explained while referring to the flowchart in FIG. 24. The 
flowchart in FIG. 24 is partly identical with the flowcharts 
in FIGS. 13 and 23, and only the different steps will be 
explained. - 

The communication control unit 65 monitors die receipt 
of a readout request at the request receipt unit 31 (CIO), a 
new MSF in the transmission stand-by buffer 62 (C21), the 
completion of the MSF transmission by the transmission 
unit 61 (Cll), and time-out MSFs (C23). 

When the request receipt unit 31 receives a readout 
request in CIO, the communication control unit 65 activates 
the readout delay timer 64 to start to count the waiting time 
for the readout request (C12), and has the array controller 60 
accumulate the readout request in the corresponding queue 
(C13). Upon detection of a new MSF in the transmission 
stand-by buffer 62 in C21, the communication control unit 
65 attaches data indicating a lower delay level to the new 
MSF (C30). When the transmission unit 61 completes the 
transmission of one MSF in C61, the communication control 
unit 65 checks whether there exists any MSF in the trans- 
mission stand-by buffer 62 (C14), and has the transmission 
unit 61 convert the flrst-in MSF therein into the cells and sets 
the delay level of the first MSF to each (C31). Subsequently, 
the communication control tmit 65 has the transmission unit 
61 transmit the resulting cells to the ATM switch 40(H) 
(C32), while resetting the counting value of the first MSF by 
the request delay timer 64 (C33). 

Upon detection of a time-out MSF in the transmission 
stand-by buffer 62 in C23, a communication control unit 65 
attaches the data indicating a higher delay level (C29). 

The structure of die ATM switch 4000 in the fifth embodi- 
ment will be explained whUe referring to FIG. 25, The ATM 
switch 4000 is of the same structure as the ATM switch 4000 
m the first embodiment except that it additionally includes a 
higher priority queue 771 and a lower priority queue 772. In 
the drawing, a solid line represents a route of the higher- 
delay-level cells, and a dashed line represents a route of the 
lower-delay-level cells. 

The higher priority queue 771 accumulates the higher- 
delay-level cells in the order of arrival, and the accumulated 
cells are exchanged to be transmitted to their respective 
destination SCBs in the same order. 
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where 



35 



50 



The delay monitor 750 includes a timer 751 and a monitor 
control unit 760. 

The timer 751 is of the same structure as the readout delay 
timer 64 shown in FIG. 10; however, the timer 751 counts 
a time between the passing of a readout request sent &om the 
SCB and the passing of the requested MSF; the counted time 
is referred to as the return time. Also, a time out Tm2 for the 
timer 751 is determined using Equation 7 as follows in 
advance. 

60 



(7) 



Tfl is the minimum delay time between the transmission 65 
of the readout request by the SCB and the receipt of the 
same by the delay monitor 750; and 
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The lower priority queue 772 accumulates the lower- 
delay-level cells in the order of arrival, and the accumulated 
cells are exchanged to be transmitted to their respective 
destination SCBs in th same order when no cells are accu* 
mulated in the higher priority queue 771. 5 

The operation of the ATM switch 4000 when transnutdng 
the cells to their destination SCBs (herein SCB 3000} will be 
explained while referring to FIG. 26. In the drawing, INPUT 
6a is an input signal to the ATM switch 4000 fmm die MSFS 
1000, and INPUT 6£> is the input signal to the ATM switch ia 
4000 &om the MSFS 1001, while OUTPUT 6c being an 
output signal from the ATM switch 4000 to the SCB 3000. 

Ceils 6dl, 6dl, and 6d3 are the lower-delay-levd cells 
stored in the lower priority queue 772 as indicated by the 
dashed line. 

Cells 6^1, 6e2, and 6e3 are also the lower-delay-level 
cells stored in the lower priority queue 772 as are with the 
Cells 6J1, 6d2, and 6d3. 

Cells 6/1, 6/2, and 6^ are the high-delay-level cells stored 
in the higher priority queue 771 as indicated by the solid 20 
line. 

In this way, the cells from the transmission unit 61 are 
stored selectively into either the higher priority queue 771 or 
lower priority queue 772 depending on their delay level, and 
transmitted to the SCB 3000 in the order of priority. Thus, ^ 
the cells 6/L, 6/2, and 6fl are transmitted before the other 
cells 6^, 6d2, 6d3, 6el, 6^2, and 6e3 are transmitted. 

By controlling the priority at the ATM switch 4000, the 
time between the MSF transmission from the MSFSs and the 
receipt of the MSF.by the SCBs can be shortened even when 
it takes a long time for the transmission unit 61 to transmit 
the cells (MSFs) to the ATM switch 4000. As a consequence, 
the MSFs are received by the SCB at regular intervals even 
when they are transmitted at different timing from the 
MSFSs. 

The readout delay timer 64 may be activated upon receipt 
of the readout request to count the delay time, and the 
priority may be determined based on the delay time. 

Sixth Embodiment 40 

In the sixth embodiment, the ATM switch 4000 is replaced 
with a network 740 consisting of a first ATM switch 741, a 
second ATM switch 745, and a delay monitor 750 as shown 
in FIG. 27, The first ATM switch 741 and second ATM 45 
switch 745 are connected to each other by a data line 10 
(DLIO), and the delay monitor 750 monitors the cells 
transmitted via the DLIO. Note that like in the fourth 
embodiment, the cells are also discarded by the SCBs in this 
embodiment 



Tgl is the minimum delay time between receipt of the 
readout request by the delay monitor 750 and the 
receipt of the requested MSF by the SCB. 

The monitor control unit 760 controls the delay monitor 
750, and the operation thereof will be explained while 
referring to the flowchart in FIG. 28, 

The monitor control unit 760 monitors the cells traveling 
between the first ATM switch 741 and second ATM switch 
745 and a point PI on the DLIO, 

When a readout request from the SCB 3000 passes the 
point PI (C41, C42), the monitor control unit 760 activates 
the tim^ 75 1 to start to count the return time for the readout 
request (C43), Further, upon detection of the requested MSF 
at the point PI (C42), the monitor control unit 760 checks 
whether the timer 751 has counted up the time-out (C44). If 
so, the monitor control unit 760 discards the MSF (C47); 
otherwise it passes the MSF to the destination SCB, resetting 
the counting value for the MSF (C46). 

Since the delay monitor 750 discards the MSFs that are 
likely to be discarded by the SCBs, the load to the ATM 
switch 4000 can be reduced. 

The network 740 may t>e comprised of more than two 
ATM switches. 

Seventh Embodiment 

' The video server 100 of the seventh embodiment is of the 
same structure as the video server 100 of the sixth embodi- 
ment except that it discards all the MSFs in the network 740 
when the MSF requested by the readout request is judged to 
be discarded. 

For this reason, the monitor control unit 760 detects the 
sequence number M of the latest MSF and the sequence 
number M+N of the latest readout request passing through 
the delay monitor 750. Also, the monitor control unit 760 
counts a time Tm3 between the passing of the latest readout 
request (M-fN) and the passing of the latest MSF (M), and 
stores a transmission interval T& between the readout 
requests. 

Thus, the monitor control unit 760 estimates a delay time 
Tm4 b^een the passing of the readout request (M) and the 
passing of the corresponding MSF (M) using Equation 8 as 
below. 



Tm4=Tm^NTs~D 



(8) 



where 

D is the maximum balance between the readout-request 
time interval from one subscriber and 1^. 

Note that Tm4 thus calculated is the minimum delay time, 
meaning that there always occurs a least delay of Tm4. 

Given Tm4, the monitor control unit 760 discards the 
MSF (M) when Equation 9 as below is satisfied. 



rm4>wi-7n-7yi 



(9) 



where 

Til is the minimum delay time between the transmission 
of the readout request from the SCB 3000 and the 
passing of the same through the delay monitor 750; and 

T}1 is the minimum delay time between the passing of the 
MSF through the delay monitor 750 and the receipt of 
the same by the SCB 3000. 

Thus, the monitor control unit 760 operates as the flow- 
chart in FIG. 29 instead of the flowchart in FIG. 28. 
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The monitor control unit 760 monitors the arrival of a 
readout request &om the SCB 3000 at the point Fl (C51). 
Upon detection of the arrival, the monitor control unit 760 
detects the sequence number thereof and activates die timer 
751 (C52). and waits for the requested MSF to arrive (C53, 
C54). Upon receipt of the MSF, the monitor control unit 760 
de-activates the timer 751 and obtains the current counting 
value as Tm3 (C55). Accordingly, the monitor control unit 
760 detects the sequence number of the received MSF (C56) 
to find N by subtracting the MSF sequence number from the 
readout request sequence number while setting (M) as the 
MSF sequence number. Further, the monitor control 760 
finds Tm4 using Equation 8 (CSS), and checks whether 
Equation 9 is satisfied or not If Equation 9 is satisfied, the 
nwnitor control 760 discards the MSF (C61); otherwise, the 
monitor control 760 passes the MSF (C60). 

By discarding MSFs in estimation, the load to the ATM 
switch 4000 can be reduced. Also, the MSFs are received at 
regular intervals even when they are transmitted at different 
timing. 

Eighth Embodiment 

In the eighth embodiment, the video server 100 operates 
depending on a c^>acity of each queue. 

Each MSFS in this embodiment is of the structure shown 
in FIG. 50, and let the MSFS 1000 be an cxzmplc. The 
MSFS Itm comprises first through K'th queues 71 . . . 7K, 
a disk array 90 including first through K*th hard disk drives 
91 . . . 9K interconnected via a SCSI and readout units 101 
. . . lOK, a queue length management unit 110, a dummy 
request storage unit 120, first through K*th tagged request 
number storage units 121 .. . 12K, a first-request storage unit 
130, a tag attachment unit 135, a selection specification unit 
140, an array controller 60, a transmission stand-by huffier 
62, and a transmission unit 61. Like components are labeled 
with like reference numerals with respect to the first embodi- 
ment, and the description of these components is not 
repeated. 

The first through K*th queues 71 ... 7K are of the same 
structure as the queues 41 ... 4K in the first embodiment; 
however, each queue has two predetermined queue lengths 
(capacities) as an authorization granting threshold and an 
au^orization transferring threshold and stores a dummy 
request besides the readout requests. 

Hereinafter, the readout requests stored in the first queue 
71 are referred to as the queue 71' s readout requests, and the 
MSFs readout as per the queue 71' s readout requests are 
referred to as the queue 71's MSFs. Similarly, the readout 
requeste stored in the second and third queues 72*73 are 
referred to as the queue 72's readout requests and queue 73*s 
readout requests respectively. 

The audiorization granting threshold is a threshold used to 
judge whedier authorization should be granted to a particular 
queue, which will be described more in detail while referring 
to FIGS. 31A and 31B. As was described in the first 
embodiment, the accumulated readout requests are retrieved 
from each queue in a predetermined sequence; however, 
there is a case where it is desirable to give a priority to a 
specific queue (herein the second queue 72) when it accu- 
mulates a large number of readout requests. For this reason, 
the authorization granting threshold is set in this embodi- 
ment in the queue length, so that the authorization will be 
given to a queue when its queue length exceeds the thresh- 
old. In case of FIG. 31 A. although a readout request is to be 
retrieved from the fourth queue 74, the second queue 72 
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grants the authorization from the foith queue 74; for the 
second queue 72 accumulates a considerable number of 
readout request exceeding the threshold. 

Hie authorization transferring du^old is another thresh- 
old used to judge whether the authorization should be 
transfened to a queue having longer queue length. Note that 
the authorization transferring threshold is set lower than the 
authorization granting threshold. 

The dummy request is the data of the same size as the 
readout request; it is not used to read out the MSFs but to 
adjust the length of a queue that has given the authorization 
to another queue. In case of FIG. 31B, since the fourth queue 
74 gives the authorization to the second queue 72, the 
dummy request is stored in the fourth queue 74 to adjust the 
length thereof. 

The disk array 90 is under the control of the control 
command in the readout request as was with the disk anay 
50 of the first embodiment However, the sttucture of the 
hard disk drives 91 ... 9^ forming the disk array 90 is 
different, and let the hard disk drive 91 be an example. The 
hard disk drive 91 comprises a disk whose memory area is 
divided into a set of sectors each storing 1024-byte data of 
the MSF, a disk driving system, a readout head for reading 
out the data form the sectors, a seek system for seeking the 
head, a readout unit 101 responsible for the data readout 
within the hard disk drive 91, a command execution unit for 
reading out the data from the sectors by controlling the disk 
driving system and seek driving system, and a cache for 
temporarily storing the data readout from the sectors. 

The operation of the hard disk drive 91 and readout unit 
101 will be explained with referring to the flowchart in FIG. 

32 d^ailing the operation of the readout unit 101 and HG. 

33 showing the state diagram of the hard disk drive 91. 
The readout unit 101 regularly checks whether die first 

queue 71 has accumulated a readout request or not (SUO). 
When the queue 71 has accumulated the readout request, the 
readout unit 101 retrieves the first-accumulated readout 
request from the first queue 71 (Sill), and the queue length 
management unit 110 decrements the queue length by one to 
update the length diereof (S112); this will be described more 
in detail below. Subsequently, the readout unit 101 judges 
whether the retrieved readout request is dummy or not 
(S113). In case of a dummy request, the readout unit 101 
discards the same (S114) to reUim to SUO, otherwise, the 
queue length management unit 110 gives a readout duection 
to the readout unit 101, which delivers the control command 
contained in the retrieved readout request to the command 
execution unit (S115), and waits for the requested MSF to be 
stored in the transmission stand-by buffer 62 (S116), 

The MSFs read out from the disk per sector are stored in 
the cache each time the command execution unit executes 
the control coounand (this corresponds to "data readout state 
a" in FIG. 33). Once the cache receives the requested MSF 
("data transmission stand-by state p'O, the requested MSF is 
transmitted to the transmission stand-by buffer 62 ("data 
transmitting state 7"). When the transmission completes 
("available state a"), the readout unit 101 delivers the 
retrieved readout request to the first-request storage unit 130 
(S117), and waits for the following readout request (SllO). 

ThQ queue management unit 110 manages the queue 
length, which wiU be explained while referring to the 
flowchart in FIG. 34 using the first queue 71 and hard disk 
drive 91 as an example. 

Hie queue length management unit 110 monitors the 
receipt of a readout request for the MSF stored in the haid 
disk drive 91 (SlOO). When the receipt is detected, the queue 
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length maxuLgement 110 refers to the queue length of the liist 
queue 71, where the readout request is to be accumulated, to 
judge whether the queue length exceeds the authorization 
granting threshold (SlOl). 

When the queue length has not reached the authorization 5 
granting threshold, the queue length management unit 110 
has the array controller 60 accumulate the readout request in 
the first queue 71 (S104); otherwise it directs the tag 
attachment unit 135 to attach the tag to the readout request 
(S102). Subsequ^y, the queue length management unit jq 
110 updates the value in the first tagged-request numto 
storage unit 121 by incrementing the value by one (S103), 
and has the array controller 60 accumulate the readout 
request in the first queue 71 (S104). Then, the queue length 
management unit 110 updates the length of the first queue 71 
by incrementing the queue length by one (S105), and waits 
for the following readout request (SlOO). 

The tag attachment unit 135 attaches the tag to the readout 
request by establishing an identification area in the readout 
request to set a distinguishable value therein. 

The dummy request storage unit 120 stores the dummy 
request into the fint through K'th queues 71 . . . 7K und^ 
the control the selection specification unit 140. 

Each of the fint through 12K'th tagged-request numbo- 
storage units 121 .. . 12K holds the number of tagged 25 
readout requests. 

The first-request storage unit 130 is a memory whose 
memory area is divided into K sections, K miatches with the 
number of the hard disk drives and queues within one 
MSFS, and each section includes an identification area. Tlie 
readout requests processed by the readout units 101, 102, . 
. . , lOK are written into the K sections respectively, and the 
state of each hard disk drive is written into the identification 
area by the corresponding readouts units 101, 102, . . . , lOK. 

The selection specification unit 140 refers to the readout 35 
request stored in ttie first-request storage unit 130, and 
detennines which MSF should be transmitted out of the 
MSFs stored in the transmission stand-by buffer 62 based on 
the queue length managed by the queue length management 
unit 110 and the values held in the first through 12K*th 40 
tagged-request number storage unit 121 . . . 12K, and du-ects 
the transmission unit 61 to transmit the determined MSF. 
Hie operation of the selection specification imit 140 will be 
explained while referring to the flowchart in HG. 35. In the 
drawing, k and j (k is not equal to j) are the variables that 45 
specify the queues and tagged-request number storage units 
within one MSFS. 

The selection specification imit 140 retrieves a readout 
request identified by a predetermined sequence number &om 
the first-request storage unit 130, and specifies the queue 50 
(k'th queue) that had stored the readout request (S120). 
Further, the selection specification unit 140 checks whether 
the k'th queue stores any tagged readout request using the 
value in the k*th tagged-request number storage unit 1^ 
(S200). When the k'th queue stores the tagged readout 55 
request, the selection specification unit 140 has the trans- 
mission stand-by buffer 62 transmit the MSF corresponding 
to the k*th queue to the transmission unit 61 (S201). Accord- 
ingly, the transmission unit 61 judges whether the readout 
request is attached with a tag or not (S202). In case of a 60 
. tagged readout request, the selection specification unit 140 
decrements the value in the k'th tagged-request number 
storage unit 12k by one; for the number of the readout 
requests requiring a transmission process time has decreased 
(S203). Then, the selection specification unit 140 waits until 65 
the transmission imit 61 completes the transmission (S204), 
and retrieves the following readout request (S120). 



As a result, the MSF read out as p^ the readout request 
arriving at the request receipt unit 31 first is transmitted to 
the request sender SCB (herein 3000) fiom the hard disk 
drive 91. But transmittmg the MSF corresponding to the k'th 
queue first, the delay dme caused in reading out the 
requested MSF can be compensated. 

When the value in the k'th tagged-request number storage 
unit Uk exhibits or the k'th queue stores no tagged 
request in S200, the selection specification unit 140 checks 
whether the k'th queue's length exceeds the authorization 
transferring threshold or not (S205). When the queue length 
exceeds the authorization transferring threshold, the selec- 
tion specification unit 140 judges that the k'th queue still 
stores a number of requests, and accordmgly has the trans- 
mission stand-by buffer 62 transmit the MSF corresponding 
to the k'th queue to the transmission unit 61 (S201). Then, 
the selection specification unit 140 judges whetiier the 
readout request that has readout the MSF corresponding to 
die k'th queue is attached with the tag or not (S202). In case 
of a tagged readout request, the selection specification unit 
140 decrements the value in the k'th tagged-request number 
storage unit 12k by one (S203); for the number of the 
readout requests has decreased. Otherwise, the selection 
spedficatibn unit 140 leaves the value in the k'tii tagged- 
request number storage unit 12it intact When die queue 
length has not reached the authorization transferring tluesh- 
old in S205, the selection specification unit 140 checks 
whetiier die first-request storage unit 130 stores the request 
of the o±cr queues (S206). When the first-request storage 
unit 130 stores the request of the other queues, the selection 
specification urut 140 refers to such request (the j'th queue's 
request) (S213), and checks whether the value in the j'tii 
tagged-request number storage unit 12/ exhibits "0" (S207), 
When the value does not exhibits **0", the selection speci- 
fication urut 140 has the transmission stand-by buffer 62 
transmit the MSF corresponding to the j'th queue to the 
transmission unit 61 ($209). 

In this way, the MSF corresponding to die j'tii queue is 
transmitted before the MSF corresponding to the k'th queue, 
and thus the selection specification unit 140 has the k'th 
queue accumulate the dummy request to prolong the length 
tiiereof (S210). Then, the selection specification unit 140 
judges whether die readout request tiiat has read out the MSF 
corresponding to the j'th queue is attached with die tag or 
not (S211). In case of a tagged readout request, the selection 
specification unit 140 decrements tiie value in the j'di 
tagged-request number storage unit 12; by one (S212); for 
the number of the readout requests has decreased. Other- 
wise, the selection specification unit 140 leaves the value in 
the j'th tagged-request number storage unit Hj intact 

Subsequentiy, the selection specification unit 140 waits 
for the transmission unit 61 to complete the transmission 
(S204), and retrieves die following readout request from the 
first-request storage unit 130, and repeats the above-de- 
scribed operation (S120). 

By giving a higher priority to a queue storing a larger 
number of readout requests, the delay tunes between die 
receipt of the readout requests and the transmission of the 
requested MSFs vary in a small range. In addition, since die 
hard disk drives widi a low transmission rate can be used, the 
manufacturing cost can be saved. 

The dummy request storage unit 120 stores one dummy 
request under the direction of the selection specification unit 
140, and the queue length is incremented by one in this 
embodiment; however, the dummy request storage urut 120 
may store more than one dummy request and the queue 
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length may be incremented by one fifth or five for one 
dummy request 

Ninth Embodiment 

In the ninth embodiment, in addition the operation of the 
eighth embodiment, the time required to transmit the 
requested MSF is compared based on the queue length to 
determine from which queue the request should be trans- 
mitted. 

Accordingly, each MSFS in the ninth embodiment addi- 
tionally includes a plurality of delay value hold units 141 . 
. . 14K and excludes the dummy request storage unit 120 as 
shown in FIG. 36. 

The delay value hold unit 141 . . . 14K correspond to the 
queues 71 . . . 7K respectively, and each hold the dday value 
of their respective queues and an authorization tran^erring 
threshold. The delay value referred herein is the sum of the 
process time required at each readout unit and the transmis- 
sion time required at the transmission unit 61 multiplied by 
the number of the requests stored in the correspondmg 
queue. The delay value is periodically computed and if the 
request is larger than the value held in the corresponding 
delay value hold unit, the latter is updated with the former. 

The operation of the queue length management unit 110 
in this embodiment will be explained while referring to the 
flowchart in FIG. 38. Since the flowchart in FIG. 38 is partly 
identical with the flowchart in FIG. 34, only the different 
steps will be explained. 

After S105, the queue length management unit UO esti- 
mates the process time using the first queue 71*s length 
(S106), and judges whether the estimated process time 
exceeds the value held in the corresponding delay value hold 
unit 141 (S107). When the former exceeds the latter, the 
queue length management unit 110 updates the latter with 
the former (S108). In this way. the delay value is updated 
each time the queue accumulates a readout request. 

Because the dummy request storage unit 120 is excluded 
in this embodiment, each readout unit operates by following 
the flowchart in HG. 37 instead of FIG, 32. Since two 
flowcharts are partiy identical, only the different steps will 
be explained. 

After S112, the readout unit 101 proceeds to S115 and 
onwards. When the first queue 71 does not accumulate any 
readout request in SUO, the corresponding readout unit 101 
resets the value in the delay value hold unit 141 to ''O'' 
(S118), and returns to SllO. 

Also, the selection specification unit 140 operates by 
following the flowchart in FIG. 39 instead of the flowchart 
in FIG. 35. Since two flowcharts are partly identical, only 
the different steps will be explained. 

When the number of tags in the k'th queue exhibits '"O" in 
S200, the selection specification unit 140 checks whether the 
delay value exceeds the authorization transferring threshold 
or not (S300). When the former exceeds the latter, the 
selection specification imit 140 proceeds to S201 and trans- 
mits tiie MSFs corresponding to die k'th queue 7k until the 
former falls below the latter; otherwise it proceeds to S206. 

When the selection specification unit 140 directs the 
transmission unit 61 to transmit the MSF corresponding to 
the j'th queue in S209, the selection specification unit 140 
updates the value in the delay value hold unit 14k (S301), 
and proceeds to S211. Tlie amount of update equals to the 
waiting time caused by giving the k*th queue a lower 
priority, making the delay value in the delay value hold unit 



10,841 

28 

14ib larger. Thus, it becomes easy for the delay value to 
exceed the autiiorization transferring threshold. 

As a result, the delay times between the receipt of the 
readout requests and the transmission of the requested MSFs 
5 vary in a small range. In addition, since the hard disk drives 
witii a low transmission rate can be used, the manu&cturing 
cost can be saved. 

The waitirig time until the MSFs are transmitted by the 
transmission unit 61, or namely a waiting time between the 
10 completion of the MSF readout and the transmission of the 
same, may be added to the delay value. 

The selection specification unit 140 selects the request in 
the fint-request storage unit 130 in the order of arriv^ at die 
request receipt unit 31 in the eighth and ninth embodiments. 
However, a counter may be additionally included, so that the 
readout units 101, 102, 103 . . . may be referred to either 
cyclic or at random each time the counter counts one. Also, 
the readout units may be referred to in the order of the time 
from the last reference, or the corresponding queue's length. 

The tags are attached by varying the value in the addi- 
tionally established identification areas in the eight and ninth 
embodiments. However, when there is an available area in 
the readout request, the tags may be attached using such 
2j available area. 

Tenth Embodiment 

In the tenth embodiment, a plurality of terminals are 
connected to one SCB. Thus, each terminal sends a request 
signal (hereinafter referred to as second data request) As 
shown in FIG. 40, the second data request comprises iden- 
tification data (USR) identifying individual terminal, pro- 
gram data (INF) for a desired program, the value (VAB) of 
a mean data receipt rate of the terminals. USR is attached to 
2j the readout requests and MSFs to identify the request-sender 
terminal, 

FIGS. 41 and 42 are the views depicting the structures of 
the SC3s and MSFSs in this embodiment respectively, and 
let the SCB 3000 and MSFS 1000 be examples. 

40 The SCB 3000 comprises a second-data-request receipt 
unit 201, a timer 202, a minimum-issuance-interval hold unit 
203, an issuance time management uiut 204. a first-data- 
request transmission judgment unit 205, a first-data-request 
transmission unit 206, an MSF distribution unit 207, and a 

4S request issuance time hold unit 208. 

Hie second-data-request receipt unit 201 receives the 
second data requests and notifies the receipt of die same, 
which will be explained while referring to the flowchart in 
FIG. 43. 

^ The second-data-request receipt unit 201 regulariy checks 
whether any second data request has arrived from the 
terminals (Rll) to notify the values of USR and VAB to the 
issuance time management unit 204 upon the receipt thereof 
(R12), while notifying the values of INF and USR to die 
first-data-request transmission judgment unit 205 (R13), and 
waits for the following second data request (Rll). 

Tlie timer 202 exhibits a current time. 

The minimum issuance interval hold unit 203 computes 
^ and stores the minimum issuance interval of the first data 
requests sent &om the SCB 3000. Hie minimum issuance 
interval is computed by multiplying VAB in the second data 
request by the number of the terminals connected to the SCB 
3000 and dividing the result by the size of the data issued 
55 accon^}anying with the issuance of the first data request. 

FIG. 44 is the format of the first data request The first data 
request corresponds to the readout request in the first 
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embodimeoL For this leason, in the first data request, USR 
is attached to each MSFP which is referred to as ADD 
hereinafter. 

Hie issuance time management unit 204 conq)utes the 
issuance interval between the first data requests, and makes 
out a schedule for the issuance of the first data requests to alt 
the connected terminals. The issuance time management 
unit 204 includes a bu£f^er (not shown) to store one scheduled 
time coming next (next issuance time) from the current time. 

The explanation of how the issuance time management 
unit 204 makes out the schedule will be explained while 
referring to FIGS. 4SA, 45B, and 45C. In this example, let 
the issuance interval be 40, and minimum issuance interval 
be 5. 

In HG. 45A, "I", "41", •*81", "121" and "161" in the 
scheduled time column are the scheduled times when the 
first data requests are issued from the terminal usrl. 
Although the column ends at "161", the issuance time 
mariagement unit 204 adds "201", "241". "281", . . . as tiie 
time elapses. 

When the terminal usr4 issues a second data request at 
"1", the issuance time management unit 204 makes out a 
sdiedule for the terminal usr4 at the minimum issuance 
intervals "5". that is to say "6'\ "46". "86", "126" as shown 
in FIG. 45B. 

Similarly, when the terminals usr2, usr3, and usr5 issue 
the second data requests at "1", the issuance time manage* 
ment unit 204 makes out the schedules at the minimum 
issuance intervals "5" for each, that is to say, "1", "6", "U", 
"16**, "21", ... for the terminals usrl, urs4, usr2, usr3, usr5 
respectively as shown in FIG. 45C. 

Tlie operation of the issuance time management unit 204 
will be explained while referring to the flowchart in FIG. 46. 

Tlie issuance time management unit 204 waits for the next 
issuance time with referring to the timer 202 (Ell), during 
which it checks the receipt of the second data request (E12). 
Upon the detection of the receipt in E12, the issuance time 
management unit 204 computes the mean issuance interval 
between the first data requests for each user (B13), and store 
the same (E14). Accordingly, the issuance time management 
unit 204 makes out a schedule for the first data requests 
based on the mean interval and minimum issuance interval 
(E15), Note that when the balance between the mean issu- 
ance interval and actual issuance int^al is larger than a 
predetermined value, the issuance interval is shortened 

When there is no second data request in E12, the schedule 
is updated by adding the following scheduled times as the 
time elapses (E15). 

Having made out the schedule, the issuance time man- 
agement unit 204 checks whether there is any scheduled 
time before the next issuance time in the buffer to retrieve 
and store die same in the buffer (E16. E17. and E18). When 
there is no next issuance time in the buffer, the issuance time 
management unit 204 stores the scheduled time in the buffer, 
and waits for another next issuance time (Ell). 

On the other hand, when the issuance time management 
unit 204 judges that it is the next issuance time in Ell, it 
directs the first-data-request transmission judgement unit 
205 to issue the first data request (E19), and has the issuance 
time hold unit 208 hold tiie issuance time (E20). Subse- 
quently, the issuance time management unit 204 stores the 
following scheduled time in the buffer (E21), and waits for 
another next issuance time (Ell). 

The first-data-request transmission judgment unit 205 
directs the first-data-request transmission unit 206 to trans- 
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mit the first data request as per the direction by the issuance 
time management unit 204. 

The operation of the first-data-iequest transmission judg- 
ment unit 205 will be explained while referring to the 
flowchart in HG. 47. 

Upon receipt of the values of USR and INF from the 
second-data-request receq>t unit 201 (JIO), the first-data- 
request transmission judgment unit 205 retrieves ADDs for 
the specified terminal from the SCF storage unit 10 in the 
SM 2000, and stores the retrieved MSFPs as ADDs with the 
corresponding USR in the form of a corresponding table 
(Jll). In this way, the first-data-request transmission judg- 
ment unit 205 stores the values of USR, INF and ADD each 
time the receipt of the second data request is notified. 

On the other hand, when the first-data-request transmis- 
sion judgment unit 205 is notified that it is the next issuance 
time by the issuance time management unit 204 (J12), it 
judges whether the correspondence table has been obtained 
or not (J13). 

When the correspondence table has not been obtained yet, 
the first-data-request transmission judgm^ unit 205 returns 
to JIO; otherwise, it retrieves the values of USR and ADD 
corresponding to the next issuance time firom the correspon- 
dence table to generate the first data request and directs the 
transmission of the same to the first-da^a-request transmis- 
sion unit 206 (J14). Then, the fir5t-<iata-request transmission 
judgment unit 205 waits for the notice of the following 
values of USR and INF and transmission direction (JIO, 
J12). 

The first-data-request transmission imit 206 transmits the 
first data requests to the MSFSs 1000, 1001, 1002, . . . under 
the direction of the first-data-iequest transmission judgment 
unit 205. 

The operation of the first-data-request transmission unit 
206 and the second-data-request receipt unit 201 will be 
explained while referring to FIGS. 48, 49A. and 49B. 

As shown in the timing chart in FIG. 49A, v/hen the 
second-data-request receipt unit 201 receives the second 
data requests at irregular intervals, the issuance time man- 
agement unit 204 transmits the same under the direction of 
the first-data-request transmission judgment unit 205, which 
receives the transmission direction for every transmission 
interval and minimum transmission interval (TIO). Thus, the 
first-data-request transmission unit 206 transmits the first 
data requests for every minimum issuaru^e interval T as 
shown in FIG. 49B. For this reason, when the second data 
requests are issued In bunt, still the first data request can be 
transmitted at regular intervals (Til). After the first-data- 
request transmission, the issuance time management unit 
204 waits for the following transmissicm direction (TIO). 

Tlie MSF distribution unit 207 includes a buffer memory 
210 and receives the MSFs transmitted from tiie MSFSs 
1000, 1001, 1002, ... as per the first readout requests sent 
from tiie first-data-request transmission unit 206, stores the 
same into the buffer memory 210, and further transmits the 
MSFs in the buffer memory 210 to the request-sender 
t^minal, which will be explained while referring to the 
flowchart in FIG. 50. 

The MSF distribution unit 207 monitors the transmission 
of MSFs and arrival of the transmission time (DIO, D12). 
Upon receipt of MSFs firom any of tiie MSFSs 1000, 1001, 
1002, . . . , the MSF distribution unit 207 receives the same 
(DIO) and stores the same into the buffer memory 210 
(Dll); otiierwise, it waits for the MSFs. 

Subsequentiy, the MSF distribution unit 207 refers to the 
timer 202 to check whether it is the time to transmit the 
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MSFs (D12). When it becomes the right time, the MSP 
distribution unit 207 judges whether the buffer memory 210 
stores any MSF (pl3), and identifies the request-sender 
terminal using the value of USR attached thereto (D14), 
sending the MSF to the identified request-sender terminal 5 
(D15). Subsequendy, the MSF distribution unit 207 resumes 
die monitoring the transmission of MSFs and arrival of the 
transmission time (DIO. D12). 

The request issuance time hold unit 208 stores the time 
when the direction of the issuance of the first data request 10 
was given last 

Next, the MSFS 1000 in the tenth embodiment will be 
explained As is shown in FIG. 42, the MSFS 1000 com- 
prises a first-data-request receipt unit 301, a data transmis- 
sion interval hold unit 302, a timer 303, a data readouttrans- 
mission control unit 304, data-cluster-transmission directing 
time hold unit 305, a transmission unit 306, the disk array 50 
including the hard £sk drives 51 . . . 5K. 

Tlie disk array 50 in this embodiment is of the same 
structure in the first embodiment; however, it stores the ^ 
MSFs in the form of data clusters. Hie data cluster referred 
herein is a storage unit of the same data size as the MSF. 

Each data cluster includes identification data called a FLS 
value. The hard disk drives 51 . . . 5K store the SCSI number 
of the disk storing the MSF, disk numb^, and the logical 
block number indicating the MSF storage location in the 
FLS value. 

The data request receipt unit 301 receives the first data 
requests sent firom the SCB 3000, 3001, 3002, . . . , and 30 
notifies the values of USR and ADD contained therein to the 
data readouttransmission control unit 304, which wiU be 
described more in detail while referring to the flowchart in 
FIG. 51. 

The data request receipt unit 301 checks regularly 35 
whether the first data request is received or not (RIO). When 
the first data request is received, the first-data-request receipt 
unit 301 notifies the values of the USR and ADD contained 
therein to the data readouttransmission control unit 304 
(Rll, and waits for the following readout request (RIO). 40 

The data transmission interval hold unit 302 holds the 
interval between the data transmission within one data 
cluster. The data transmission interval in this embodiment is 
found by dividing the mean value of the arrival times of the 
first data readout requests addressed to one MSF by the 
number of the data clusters. 

The transmission interval held in the data transmission 
interval hold unit 302 is referred to as data transmission time 
together with the transmission directing time held in the 
data-cluster-transmission directing time hold unit 305. 

The timer 303 counts the time. 

The data readouttransmission control unit 304 manages 
the data related to the data clusters of the readout requests, 
and controls the readout and transmission of the data based 55 
on the received first data requests, which will be explained 
more in detail while referring to the flowchart in HG. 52. 

The data readouttransmission control unit 304 checks 
whether the values of USR and ADD are notified from the 
first-data-request receipt unit 301, or it is the data transmis- 60 
sion time (C60, C64). When the values of USR and ADD are 
notified from tiie first-data-request receipt unit 301, the data 
readouttransmission control unit 304 stores the same (C60, 
C61), and retrieves the FLS value in the data cluster from the 
ADD value to store die same (C62, C63). The hard disk 65 
drives 51 . . . 5K store the SCSI number for the disk storing 
the MSF, and the disk number, and the logical block number 
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in relation widi the value of PLS. The SCSI, disk, logical 
block numbers are included in the ADD value (MSFP), and 
thus, when the data transmission time comes (064), the data 
readouttransmission control unit 304 successively reads out 
the MSFs as per the data clusters corresponding to the 
readout requests, and directs the transmission unit 306 to 
transmit the MSFs. In so doing, the data readout-transmis- 
sion control unit 304 notifies the values of the data clusters 
and USR specifying the destination to the transmission unit 
306 (C65). Subsequentiy, die data readouttransmission con- 
trol unit 304 refers to the timer 303 (C66), and has the 
data-cluster-transmission directing time hold unit 305 store 
the transmission time when the readout and transmission of 
the MSFs are directed (C67), and waits for the following 
notice of the values of USR and ADD, and the arrival of the 
following transmission time (C60, C64). 

The transmission unit 306 retrieves the data firom the 
respective hard disk drive under the direction of the data 
readout.transmission control unit 304 to transmit the same to 
die SCB (herein 3000), which will be detaHed by tiie 
flowchart in FIG. 53. 

The transmission unit 306 waits for the transmission 
direction from the data readout-transmission control unit 
304 (T70). When the transmission direction arrives, the 
transmission unit 306 receives the MSFs read out by the data 
readout-transmission control unit 304 to transmit the same to 
die ATM switch 4000 (T71). 

By transmitting the first data requests at regular intervals 
longer than the minimum issuance interval, the requests and 
MSFs will not be transmitted intensively. As a result, the 
traffic jam within the ATM switch 4000 will be mitigated, 
upgrading the efficiency of tb& ATM switch 4000. 

The minimum issuance interval may be shortened when 
the number of the first data requests waiting to be transmit- 
ted exceeds a predetermined threshold 

The second data request may be formatted differentiy 
from the example in this embodiment as long as the iden- 
tification data identifying the request data, and the destina- 
tion of the MSFs are included. 

Also, the first data request may be formatted differentiy 
form the example in this embodiment as long as die iden- 
tification data identifying the request-sender SCB and die 
logical address specifying the storage, location of the 
requested MSF are included. 

The order of the arrival of die second data requests may 
be stored to issue the corresponding first data requests at 
nunimum. issuance intervals. 

Although the data cluster is used as a memory unit of the 
MSF, other units can be used as long as the MSF's storage 
location can be specified. 

The bufier memory monitor unit 22 in the first embodi- 
ment may be installed between the buffer memory 210 and 
first-data-request transmission unit 206 to transmit the first 
data requests depending on the available capacity of the 
buffer memory 210. 

Eleventh Embodiment 

In the eleventh embodiment, when a plurality of SCBs 
sends out the readout request to one MSF, the MSF are 
copied in the matching number. 

Thus, ATM switch 4000 is connected to a copy unit 6000 
as shown in HG. 54. 

The copy unit 6000 copies tiie data in the cells in 
accordance with a copy list to transmit the resulting cell 
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copies to their respective destinations. Hie copy list referred 
herein is a list of the destinations for each cell copy, and 
generated by the MSFs. The cell-copy technique is detailed 
in U.S. Pat No. 5.287^30 issued on Feb. 15, 1994, and the 
further explanation is omitted herein. 

To make the cell copies, the array controller 60 operates 
by following the flowchart in FIG. 55 instead of FIG. IIB; 
for the array controller 60 in this embodiment includes a flag 
register, and sets a flag F in accordance with each readout 
request accumulated in the queues. 

The array controller 60 monitors the arrival of a readout 
request regulariy (S3301). Upon detection of the readout 
request, the array controller 60 judges whether the cone- 
sponding hard disk drive is reading out the MSFs (S5302). 
When the hard disk drive is not reading out the MSFs, the 
array controller 60 outputs the readout request to the hard 
disk drive (S3303). While the bard disk is reading out MSFs, 
the aiiay controller 60 monitors the arrival of the following 
readout request (S3301). When the following readout 20 
request arrives, the array controller 60 inquires the corre- 
sponding hard disk drive wh^er it has completed the MSF 
readout (S3302). When the hard disks is still reading out the 
MSFs, the array controller 60 discriminates the MSF cor- 
responding to the readout request, and judges whether any 
readout request for the same MSF has been accumulated in 
the corresponding queue (S3307). When such readout 
request has been accumulated in the queue, the array con- 
troller 60 sets the flag F of the readout request to "1" and 
accumulates the readout request in the queue (S5308). 

On the other hand, when there is no readout request for the 
same MSF, the array controller 60 accumulates the readout 
request in the queue, setting the flag F of the readout request 
'Xr* (S3309). 

Having set the flag F, the array controller 60 resumes the 
monitoring of the arrival of another readout request (S3301). 
and waits the hard disk drive to complete the MSF readout 
(S3305. S3304). 

When the hard disk drive completes the MSF readout, the 
array controller 60 checks whether there is any readout 
request accumulated in the queue (S3306) to retrieve the 
first-accumulated readout request therein, and judges 
whether the flag F of the retrieved readout request is set to 
"1". When the flag F is set to "1", the array controller 60 
retrieves the readout requests requesting the same MSF from 
the queue to generate the copy list (S3313). Then, the array 
controller 60 transmits the copy list thus generated to the 
copy unit 6000, and deletes the readout requests on the list 
from the queue, cutting the queue length shorter. Having 
deleted the retrieved readout requests, the array controller 60 
reads out the MSF as per the readout request from the hard 
disk drive, transmitting the same to the copy unit 6000 
(S3314). 

Ihe copy unit 6000 receives the copy list and MSF 
converted into the cells, and copies the MSF in a matching 
number with the nuniber of the readout requests on the copy 
list Havirig copied the cells (MSF), the copy unit 6000 
varies the addresses on the copy list into the cells separately, 
and outputs the same to the ATM switch 4000. The cell 
copies (MSF copies) ou^utted to the ATM switch 4000 are 
delivered to their respective request-sender SCBs. 

By copying the cells (MSF) and sending the same when 
a plurality of readout requests are sent to one particular MSF 
at a time, the requested MSF can be transmitted to their 
respective request sender SCBs simultaneously, speeding up 
the MSF^'s operation. 
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In the twelfth embodiment, the MSFSs also serve as the 
copy unit 6000. 

Thus, the comnmnication control unit 65 includes an MSF 
transmission management table as shown in FIG. 56. 

The MSF transmission management table is used to dived 
the received readout requests into groups for each MSF, and 
consists of entries including three columns: a requested MSF 
identification number, a destination, and a Ust of oth^ 
desdnations. 

The requested MSF identification number column exhib- 
its the MSP sequence numbers identifying the individual 
MSFs requested by the readout requests, which was men- 
tioned in the first embodim^ The destination column 
exhibits the address of the SCB which has sent the readout 
request to one particular MSF first The other destination list 
column exhibits the addresses of the other SDBs that have 
sent the readout request to the same MSF second aiul 
onwards. 

For sample, from left to right in the top of the MSF 
transmission management table. **2l3(f* is the identification 
number of one MSF, "1" is the address of the SCB that has 
sent the readout request to the MSF identified as '*2130'\ and 
'*i(f' is the address of the SCB that has also sent tiie readout 
request to the same MSF following the SCB "10*\ 

In addition to the function described in the first embodi- 
ment, the communication control unit 65 operates by fol- 
lowmg the flowcharts in FIGS. 57 and 58, which will be 
explained in the following with referring to FIG. 56 as well. 

When the request receipt imit 31 receives a readout 
request (SlOOl), the communication control unit 65 checks 
whether the identification numbw of the MSF requested by 
the readout request is listed on the MSF transmission 
management table (S1002). Assume that the SCB 3004, 
whose address is "5", has requested the MSF identified by 
"2130" (S1003), then the communication control unit 65 
writes the address "5" in the other destination list of the MSF 
"2130" in the MSF transmission management table. 
(S1004). 

When there is no corresponding MSF in the MSF trans- 
mission management table in S1003, the communicadon 
control unit 65 adds a new entry by writing the address of the 
requested MSF and its destination (S1005, S1006). 

When there is any MSF in the transmission stand-by 
bufler 62 (SI102 in FIG. 58), the communication control 
unit 65 selects the first-in MSF therein (S1102) to send the 
same to the request-sender SCB (S1103). Having transmit- 
ted the first-in MSF, the communication control unit 65 
checks whether the identification of the transmitted MSF is 
listed on the MSF transmission management table (S1104). 
If so, the communicadon control unit 65 retrieves all the 
addresses in the other destinations list column to copy the 
transmitted MSF for the number of the retrieved addresses 
(S1109), writing the retrieved addresses into the MSF copies 
separately (SlllO). 

In case of HG. 56, the transmission stand-by bufler 62 
stores the MSF identified by "6521". Then, the communi- 
cation control unit 65 retrieves the addr^es "1" and "3" 
from the MSF transmission management table, makes two 
copies of the MSF, writes the addresses "1" and "3" in the 
MSF copies respectively, and has the transmission unit 61 
transmit die MSF copies (Sllll). Subsequentiy, the com- 
munication control unit 65 deletes the transmitted MSF from 
the transmission stand-by huffier 62, and the entry thereof in 
the MSF transmission management table as well (S1107, 
S1108). 
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By copying the MSF and sending the same, the requested 
MSF can be transmitted to their respective request sender 
SCBs when a plurality of readout requests are sent to one 
particular MSF, upgrading the operating speed of the MSFS. 

Thirteenth Embodiment 

In the thirteenth embodiment, the SCF of the requested 
video are obtained partially. 

Thus, the MSFP transmission control 23 includes a par- 
tial-SCF buffer (not shown) instead of the SCB buffer, and 
an SCF obtainment control unit (not shown) instead of the 
selection signal separation unit 20 for monitoring an avail- 
able cqiacity of the partial-SCF buffer to retrieve SCF from 
the SM 2000 according to the available capacity. 

The operation of the SCF obtainment control unit will be 
explained while referring to the flowchart in FIG. 59. 

The SCF obtairmient control unit regularly monitors 
whether the MSFP transmission control unit 23 transmits an 
SCB obtaiimient request (S1301). Upon detection of the 
SCF obtainment request, the SCF obtainment control unit 
requests the transmission of lO-minute long MSFPs out of 
the corresponding SCF to the SM 2000 (S1302). Upon 
receiptofthe MSFPs, the MSFPtransmission control unit 23 25 
generates the readout request using the MSFPs, and trans- 
mits the same to the corresponding MSFSs (S1303). 

Also, the SCF obtainment control unit regularly monitors 
a playback mode request (S1304). Upon detection of the 
playback mode request, the SCF obtainment control unit 
determines the remaining level to the playback mode 
(S1305); otherwise, the SCF obtaixmicnt control unit con- 
tinues the monitoring, leaving the current remaining level 
intact (S1306). 

The remaining level referred herein is a threshold used to 35 
det^mine whether the following partial SCF should be 
requested by judging the amount of the partial-SCF buffer. 
Assume that 10% is the remaining level for the normal 
playback mode, then the SCF obtaiimient control unit 
requests the following partial SCF when the remaining 40 
MSFPs in the partial-SCF buffer becomes 10% of the 
capacity thereof. Similarly, assume that 30% is the remain- 
ing level for the fast playback mode, then the SCF obtain- 
ment control unit requests the following partial SCF when 
the remaining level of the MSFPs in the partial-SCF buffer 45 
becomes 30%, and assume that 3% is the remaining level for 
the slow playback mode, then the SCF obtainment control 
unit requests the following partial SFC when the remaining 
level of the MSFPs in the partial-SCF buffer becomes 3%. 

Having set the remaining level, the SCF obtaimnent 
control unit checks whether the remaining MSFPs is less or 
more than the remaining level (S1307). When the former is 
less than the latter, the SCF obtainment control unit requests 
the transmission of the following partial SCF (S1308). 

Further, the SCF obtainment control unit checks the last 
MSFP in the SCF (S1309), If the last MSFP is not included, 
the SCF obtairmient control unit resumes the monitoring on 
the playback mode (S1304); otherwise, it waits for another 
SCF obtainment request (S1301). 

Since the SCB stores the SCF partially, a considerably 
long SCF can be stored in the SCF buffer with a small 
capacity. 

The charge management unit 13 may detect how many 
MSFPs in one SCF are retrieved, so that the chaises become 65 
directiy proportional the length of the video transmitted to 
the terminal. 
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In the fourteentii embodiment, the video stored in the 
MSFSs, 1000. 1001, 1002 are re-written. Thus, the video 
server 100 in diis embodiment is installed at the CATV 
station, and connected to the video players within the 
statioiL 

The structure of a system using the video server 100 in the 
fourteenth embodiment is shown in FIG. 15. 

The system controls all the units in the station, and 
comprises a total system manager (TSM) 910 responsible 
for the control of the transmission route between the termi- 
nals and video server 100 as well as the management of the 
charges and programs, an encoder 920 for converting a 
video signal into the MPEG 2 format, and a transmission 
unit 940 for converting an analog signal from a conventional 
analog broadcast unit 930 into a digital signal to multiplex 
the same. 

FIG. 60 depicts the structure of the SM 2000 in this 
embodiment The SM 2000 includes an available area man- 
agement unit 12 and an available area sequence data notice 
unit 15 in addition to the structure shown in FIG. 5. 

Hie available area management unit 12 manages over- 
writable areas within the memory area of the MSFSs 1000, 
1001, 1002, ... as recordable areas. The data related to the 
availiable areas are used for such management; the data 
related to the available areas are used as a pointer for the 
overwritable area, and contain an area identifier, the address , 
of the corresponding MSF, and location of the available area 
in the disk array 50 in the MSFS. Thus, the available area 
data are of a similar structure as the MSFP shown in FIG. 4 
except that they additionally include the area identifier and 
that a "write" command is assigned. The available area data 
include the parameters for the write command to the disk 
array, and thus they also serve as a disk control command to 
write the data by accessing to the disk array. 

The available area sequence data notice unit 15 accepts a 
record request, edits a write control file (WCF) for the video 
to be recorded in the available area, sending the WCF to the 
request-sender SCB. lb be more specific, upon receipt of the 
record request, the available area sequence data notice unit 
15 align the available area data for each MSFS in a prede- 
termined sequence: the available area data related to the 
MSFS 1000 is placed first, and the available area data related 
to the MSFSs 1001 and 1002 are placed second and third 
respectively. Having aligned the available area data, or 
edited the WCF, the available area sequence data notice unit 
15 transmits the WCF to the FD 5000, so that it converts the 
WCF into an SCF to have the SCF storage unit 10 store the 
same for the recorded video. 

The recording operation will be explained while referring 
to the timing chart in FIG. 16. 

Prior to the video writing, the TSM 910 has the available 
area sequence data notice unit 15 in the SM 2000 generate 
the WCT for the video by outputting a WCF generation 
request (WCF_Create_Req) to the SM 2000, 

When the SM 2000 receives the generation request, the 
available area sequence data notice unit 15 edits the WCF in 
the period indicated by (New__WCF_Create), transmitting 
the WCF to the TSM 910 as a request response (WCF_ 
Create^sp). Upon receipt of the WCF, the TSM 910 
outputs a record start request (Start) to the FD 5000, which 
in turn outputs a WCF obtain request (WCF_Get_Req) to 
the available area sequence data notice unit 15, and the 
available area sequence data notice unit 15 transmits the 
WCF to the FD 5000 as a request response (WCF_Get_ 
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Rsp). Accoidingly, the FD 5000 ou^uts a lecord start 
request (Start) to the encoder 920 by means of the TSM 910. 
The encoder 920 tfa^ outputs the 64-byte image data to the 
FD 5000, which converts the same into the MSF. Further, the 
FD 5000 generates a record request (MSF_Write_Req(l)) 
to write the first MSF using the available area data placed 
first in the WCF, outputting the same to the request-sender 
NfSFS 1000 (MSFsUl) together with the corresponding 
MSF. Since die record request also serves as the write 
control command to the dis^ array 50, the MSF is written 
into the disk array 50 within the period indicated as (MSF 
Record). Subsequendy. the MSFS 1000 transmits a record 
completion notice (MSF_Write_Jlsp(l)) to the FD 5000. 
which in turn receives the following 64-Kbyte image data 
from the encoder 920 and generates anodier record request 
(MSF_Write_Req(2)) to write the second MSF using the 
second available area data, and sends the same to the 
request-sender MSFS 1001 (MSFS[2]) together with the 
corresponding MSF. 

FIG. 61 depicts the structure of each MSFS of the 
fourteen the embodiment, which additionally includes a 
write request queue 410 and an MSF buffer 411 compared 
with the MSFSs in the first embodiment 

The write request queue 410 holds the write requests sent 
to its MSFS, and the write requests are processed in the order ^ 
of arrival when all the readout requests in the queues 41, 42, 
43, . . . have been processed. 

The MSF buffer 411 holds the MSFs transmitted to its 
MSFS and the MSFs are retrieved by the array controller 60 
to be stored in the disk array 50. 

The communication control unit 65 in this embodiment 
operates by following the flowcharts in FIGS. 13 and 62. 

The communication control unit 65 checks the receipt of 
a readout request, a write request, and cells (MSF), and 
whether there is any readout request in the queue furnished 
for the hard disk drive to which the write request is 
addressed (CIO in FIG. 13. C81, C82, and C83 in FIG. 62). 
Upon receipt of the write request in C81. the communication 
control unit 65 accumulates the same in the write request 
queue 410 (C84). Upon receipt of the cells (MSF) in C82, 
the communication control unit 65 stores the same into the 
MSF buffer 411 (C85). 

When all the readout requests in the queue furnished for 
the write request's addressing hard disk drive have been 
processed in C83, the communication control unit 65 suc- 
cessively outputs the write requests in the write request 
queue 410 to the array controller 60. and has the array 
controller 60 retrieve and store the MSF in the MSF buffer 
411 into the disk array 50. 

As has been stated, each MSFS in this embodiment can 
rewrite the video stored therein when there is no readout 
requests. For this reason, the video can be written while 
reading out the video at real time. 

Only a single write request queue is furnished in this 
embodiment; however, it may be furnished for each hard 
disk drive. 

In the first through fourteenth embodiments, MSFs are 
stored in the hard disk drives; however, they may be stored 
other storing media such as memory, optical disks, and video 
tapes. 

Although the present invention has been fully described 
by way of examples with reference to the accompanying 
drawings, it is to be noted that various changes and modi- 
fications will be apparent to those skilled in the art There- 
fore, unless otherwise such changes and modifications 
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depart £rom the scope of the present invention, they should 
be construed as being included therein. 
What is claimed is: 

1. A video server which transmits digital video data 
comprising frame blocks having a predetermined sequence 
and stored therein to subscriber terminals as per video 
requests conqnismg: 

a plurality of firame block servers, each including a 
con^uter interface unit, an image memory and a read- 
out control unit for the image memory, each image 
memory storing a plurality of said frame blocks non- 
consecutive with respect to said predetermined display 
sequence, the readout control unit receiving readout 
requests and in response reading out requested frame 
blocks from the image memory; 

management means for storing management data sped- 
fymg which firame block server stores which frame 
blodc in the image memory; 

a plurality of subscriber internees for receiving the video 
requests from the subscriber terminals, and in response 
sending readout requests to the firame block servers to 
readout the frame blocks forming requested digital 
image data in the predetermined sequence whfle refer- 
ring to the management Hata, and for transmitting the 
frame blocks transmitted fipom the firame block servers 
to the subscriber terminals at such timing that ensures 
continuous play; and 

exchange means for intercormecting each block server 
and each subscriber interface to transfer the fr:ame 
block servers as per the readout requests to the request- 
sender interfaces. 

2. The video server of claim 1. wherein the management 
data comprise a plurality of block pointers, eadi identifying 
a location of each frame block respectively, and including an 
address of each firame block server that stores each frame 
block respectively, and 

wherein each subscriber interface includes: 
a management data obtainment unit for receiving the 
video request from the subscriber terminal, and in 
response retrieving block pointers for the requested 
piece of digital video data fipom the management 
means; 

a readout request generation unit for generating a readout 
request for each retrieved block pointer addressing to 
the frame block server specified by the address 
included therein; 

a readout request transmission unit for transmitting the 
readout requests to the specified frame block servers, 
one readout request being transmitted at a time; and 

a frame block output unit for receiving the frame blocks 
read out as per the readout requests, and in response 
outputting the frame blocks to the request-sender sub- 
soiber terminal at predetermined timing. 

3. The video server of claim 2, wherein each subscriber 
interface further includes an estimated return time storage 
unit for storing an estimated time between a transmission of 
the readout request and a receipt of the requested firame 
block as an estimated return time, the estimated return time 
varying depending on a ficame-block readout rate of the 
frame block server, an exchange ability of the exchange 
means, and a transmission rate of the.subscriber interface in 
transmitting the requested firame block to the.subscriber 
terminal, and 

wherein the readout request transmission uxnt transmits 
the readout requests at an interval equal to the esti- 
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mated return time before the £rame block output unit 
outputs the requested frame blocks at the {deter- 
mined timing. 

4. The video server of claim 3, wherein each subscriber 
interface further includes: 5 

aretum time counter for counting an actual time required 

to transmit the readout request and receive die 

requested frame block; and 
a balance computation unit for computing a balance 

between the actual time and the estimated return time, 

and 

wherein the readout request transmission unit includes a 
transmission control unit for controlling a readout- 
request transmission in such a way that the readout 
requests are transmitted at an interval equal to the 
balance before the predetermined timing. 

5. The video server of claim 4, wherein the estimated 
return time storage unit stores the estimated return times for 
each frame block server, and 

wherein the return time counter counts the actual times for 
each frame block server, and 

wherein the balance computation unit computes the bal- 
ances for each frame block server, and 

wherem the transmission control unit controls a readout- ^ 
request transmission in such a way that the readout 
requests are transmitted to their respective specified 
frame block servers before the predetermined timing 
while referring to the balance for the frame block 
servers. 30 

6. The video server of claim 3, wherein each subscriber 
interface further includes: 

a return time counter for counting an actual time required 
to transmit the readout request and receive the 
requested frame block; and 

a return time update imit for updating the estimated return . 
time stored in the estimated return time storage unit 
with the actual time counted by the return time counter, 
and ^ 

wherein the readout request transmission unit transmits 
the readout requests at an interval before the frame 
block output unit outputs the requested frame block at 
the predetermined timing, the interval being equal to 
the updated estimated return time. 45 

7. Hie video server of claim 6, wherein the estimated 
return time storage unit stores the estimated return times for 
each frame block server, and 

wherein the return time counter counts the actual times for 
each block server, and SO 

wherein the return time update unit updates the estimated 
return times stored in the estimated return time storage 
unit with the acmal times counted by the return time 
counter for each frame block server. 

8. The video server of claim 2, wherein the frame block 55 
output unit includes: 

a frame block receipt unit for receiving the frame blocks 
addresses to the self s subscriber interface; 

a block buffer for accumulating a certain number of frame 
blocks received by the frame block receipt unit; 

an accumulated amount judgment unit for judging 
whether the block buffer stores more than a predeter- 
mined number of frame blocks; and 

an output unit for outputting the certain number of the 65 
frame blocks accumulated in the block buffer when the 
accumulated amount judgment unit judges that the 
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block buffer stores more than the predetermined num- 
ber of fr^me blocks, one frame blodc being outputted at 
a time to the request-sender subscriber terminal. 

9. Hie video server of claim 8, wherein the frame block 
output unit further includes a check unit for checking an 
overflow and an underjQow occurring at the block buffer, and 

wherein the readout request transmission unit includes a 
transmission control unit for controlling a readout- 
request transmission in such a way that the readout 
request are transmitted after the predetermined timing 
upon detection of the overflow by the check unit, and 
before the predetermined timing upon detection of the 
underflow by the check unit 

10. The video server of claim 8, wherein each subscriber 
interface further includes a detection urut for detecting an 
amount of remaining frame blocks in the block buffer, and 

wherein the readout request transmission unit includes a 
transmission control unit for controlling a readout- 
request transmission in such a way that the readout 
requests are transmitted when the amount of remaining 
frame blocks falls below a predetermined threshold. 
U. The video server of claim 8, wherein the output unit 
ouQmts the certain number of the frame blocks in the block 
buffer at predetermined intervals, one frame block being 
outputted to the request-sender subscriber terminal at a time, 
die predetermined interval varying depending on a length of 
a video played with digital image data for one frame blocL 

12. video server of claim 2, wherein each subscriber 
interface is cormected to a plurality of subsoiber terminals, 
each subscriber terminal outputting a video request indud* 
ing a terminal identifier, and 

wherein the management data obtainment unit further 
includes an identifier detection unit for detecting the 
terminal identifiers contained in the video requests sent 
from the subscriber terminals upon receipt thereof, and 

wherein the readout request transmission unit further 
includes an identifier attachment unit for attaching the 
terminal identifiers detected by the identifier detection 
unit to each readout request generated by the readout 
request generation unit, and 

wherein the readout control unit in each frame block 
server includes: 

a readout request receipt unit for detecting the terminal 
identifiers when receiving the readout requests from the 
readout request transmission unit; and 

a fr^me block transmission unit for attaching the terminal 
identifiers detected by the readout request receipt unit 
to each request frame block read out as per the readout 
requests before the transmission thereof to the request- 
sender subscriber interface, and 

wherein the fr^me block output unit further includes a 
distribution output control unit for receiving the termi- 

. nal-identifi^-attached frame blocks and in response 
outputting the same to the request-sender subscriber 
terminal identified by the terminal identifier. 

13. The video server of claim 12, wherein the readout 
request transmission unit includes: 

a most recent transmission time storage unit for storing a 
transmission time when a readout request is transmitted 
most recently; 

a transmission judgment unit forjudging whether a read- 
out request is being transmitted for another subscriber 
when the management data obtainment unit receives a 
video request from one subscriber, 

a time control unit for controlling a readout-request 
transmission for one subscriber while the readout 
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request for another subscriber is being transmitted in 
such a way that a first readout request for the video 
request from the former subscriber is transmitted after 
a certain interval firom die most recent transmission 
time, and that a second and subsequent readout requests 5 
are transmitted at predetennincxl issuance intervals - 
from the transmission of the first readout request, the 
certain int^al being found by multiplying a mean 
frame-block transmission rate of the plurality of sub- 
scriber interfaces in transmitting the frame blocks to the 
request-sender subsoiber terminals by the number of 
the connected subscriber terminals, and dividing an 
amount of data of one frame block by the resulting 
value, the predetermined issuance interval being found 
by dividirig the fimne-block data amount by the trans- 
mission rate of one frame block. 1^ 

14. The video server of claim 12, wherein the readout 
request transndssion unit includes: 

a transmission schedule generation unit for making out a 
transmission schedule of each readout request for a 
video requests upon receipt thcreofby the management 20 
data obtainment unit; 

a dock unit for showmg a current time; 

a transmission time buflOer for storing a next scheduled 
time, the next scheduled time being a scheduled time 
nearest to the current time; 

a transmission control unit for controlling a readout- 
request transmission in such a way that a readout 
request scheduled for the next scheduled time is trans- 
mitted when the clock unit shows the next scheduled 30 
time; 

a transmission scheduled time determination unit for 
determining the transmission schedule, when the man- 
agement data obtainment unit receives a video request 
from another subscriber, by setting the transmission 3S 
scheduled time for a first readout request after a pre- 
determined interval from the next scheduled time, and 
by setting scheduled times for second and subsequent 
readout requests at predetermined issuance intervals 
from the scheduled time for the first readout request; 40 

a schedule write imit for writing the transmission sched- 
uled tunes determined by the transmission scheduled 
time determination unit into the transmission schedule, 
the certain interval being found by multiplying a mean 
frame-block transmission rate of the plurality of sub- ^5 
scriber interfaces m transmitting the frame-blocks to 
the request-sender subscriber terminals by the number 
of the connected subscriber terminals, and dividing an 
amount of data of one frame block by the resulting 
value, the predetermined issuance interval being found ^ 
by dividing the frame-block data amount by the trans- 
mission rate of one frame. 

15. The video server of claim 2, wherein the management 
data are a sequential file where the block pointers are aligned 
in a same sequence as a frame-block transmission sequence, 
and 

wherein the readout request transmission unit includes: 

a playbadc mode judgment unit for receiving a playback 
mode signal from the subscriber terminal and discrimi- ^ 
nating a playback mode contamed therein; 

a first transmission unit for transmitting the readout 
requests generated with the block pointers in the 
sequence in the management data when a normal 
playback mode is discriminated; and ^ 

a second transmission unit for transmitting the readout 
requests generated with the block point^s in the 



sequence in the management data by skipping a number 
of block pomters when a fast playback mode is dis- 
criminated, the number of skipped bock pointers cor- 
responding to a video-play speed. 

16. The video server of daim 15, wherdn each subscriber 
interface includes: 

a block pointer retrieval unit for retrieving a predeter- 
mined number of block points from die management 
means in the sequence in the management data; 

a pointer huffier for holding the predetermined number of 
block pointers retrieved by the block pointer retrieval 
unit; and 

a retrieval direction unit for directing a retrieval of the 
predetermined number of blodc pointers when the 
number of block pointers remaining in the pointer 
buffer falls below a predetermined threshold. 

17. Hie video server of claim 16, wherein the manage- 
ment means further includes: 

a retrieval amount detection unit for detecting the nimiber 
of block pointers retrieved by the blodc pointer 
retrieval unit; and 

a charge unit for calculating charges for each request- 
sender subscriber based on the number of the retrieved 
block pointers. 

18. The video server of claim 2, wherein the exchange 
means is an ATM cell switch for exchanging cells, and 

wherein each image memory is a disk array comprising K 
disk drives for storing the frame blocks, and 

wherein each block pointer includes an address of each 
frame block server storing each frame block, and an 
address of the frame block in the disk array, and 

wherein the readout request is of a cell structure, and the 
readout request transmission unit writes the address of 
frame block server in a header area of the cell structure 
while writing the address of the frame block in the disk 
array in a data area of the cell structure to generate a 
readout request for each block pointer, and 

wherein the readout control unit in the frame block server 
detects the address of the frame block in each readout 
request and reads out the requested frame block by 
accessing to the address of the disk array. 

19. Hie video server of daim 18, wherein the disk array 
comprises K disk drives interconnected by a SCSI, and the 
address of the frame block is formatted for a readout 
command in a SCSI system. 

20. The video server of claim 18, wherein the readout 
comrol unit in each frame block server includes: 

K queues for holding the readout requests to read out the 
requested frame blocks from corresponding disk drives 
in an order of recdpt, one queue being furnished for 
one disk drive; 

a readout request recdpt unit for receiving the readout 
requests addressed to the self s frame block server; 

an address analysis unit for detecting the address of the 
request frame blocks contained in each readout request 
received the readout request recdpt unit and in 
response specifying the disk drives to which each 
readout request is addressed using the detected address, 
and for having the queue furnished for the spedfied 
disk drive store the readout request; 

a disk access unit for retrieving one readout request from 
the K queues, and in response accessing to a memory 
area in the spedfied disk drive at the address contained 
in the readout request to have the disk drive read out 
from the requested firame block; 
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a transmission stand-by buffer for holding the £rame 
blocks read out from the K disk drives; and 

a frame block transmission unit for retrieving the frame 
blocks from the transmission stand-by buffer to trans- 
mit to the request-sender subscriber interface. 5 

21. The video server of claim 20, wherein the frame blodc 
transmission unit includes: 

a readout request storage unit for storing a readout request 

■ for which a requested frame block has been read out 
and stored in the transmission stand-by buffer together 10 
with a corretatipn with the frame block; 

a fimne block retrieval unit for retrieving the frame blocks 
from the transmission stand-by buffer, 

a request-sender detection unit for detecting a request- 
sender subscriber interface of the readout request for 15 
the frame block retrieved from the transmission stand- 
by buffer; 

a frame block division unit for dividing the retrieved 
frame block from the transmission stand-by buffer into 
a set of sub-blocks of an equal size; 20 

a writing unit for writing each sub-block into the data area 
of the cell structure, and writing the request-sender 
detected by the request-sender detection unit into the 
header area of the cell structure; and 

a cell transmission unit for transmitting the cells written ^ 
with the sub-block and the request sender subscriber 
interface to the request-sender subscriber interface. 

22. The video server of claim 21, wherein the frame block 
transmission unit. includes: 

a monitor unit for monitoring an overflow occurring in the 30 
ATM cell switch; and 

a disallow unit for disallowing the cell transmission unit 
to transmit the cells in case of an overflow, and for 
allowing the cell transmission unit to transmit the cells 
when the overflow is eliminated. 35 

23. The video server of claim 21, wherein the readout 
control unit in each frame block server includes: 

a delay timer for counting a time for each readout request 
upon receipt thereof, a time-out occurring when the 
delay timer counts up a predetermined value; and ^o 

a delayed data write unit for writing delay data indicating 
a delay into the cells of a frame block which has been 
read out by a time-out readout request, and 

wherein the ATM cell switch includes: 

45 

a higher priority queue for storing the cells which have 

delay priority in an order of arrival; 
a lower priority queue for storing the cells which do not 

have the delay priority in an order of arrival; and 
an exchange control unit for controlling a cell exchange in 50 

such a way that the cells in the higher priority queue are 

transmitted first, and then the cells in the lower priority 

queue are transmitted. 

24. The video server of claim 20, wherein the readout 
control unit in each same block server further includes: 55 

a flat register, each bit therein corresponding to readout 
requests in the K queues respectively; 

a disk monitor unit for monitoring whether one of the K 
disk drive which stores a frame block requested by a 
readout request is reading out any other frame block, 

a requested frame block judgment unit for specifymg the 
frame block requested by the received readout request 
when the disk monitor unit judges that the disk drive is 
reading out the another frame block; ^5 

a readout request detection unit for detecting all readout 
requests requesting the from block specified by the 
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requested frame block judgment unit from the K queues 
and setting the bits for each request; 
a bit judgment unit for judging whether the bit in the flag 
register is set for a first-accumulated readout request in 
the queue when the disk monitor unit judges a comple- 
tion of the readout of the another frame block by the 
quote; 

a readout request detection unit for retrieviiig all the 
bit-set readout requests in the queue when the bit 
judgment unit judges the bit is set for the first-accu- 
mulated readout request; and 

a request-sender list generation unit for detecting the 
request-sender subscriber interface for each readout 
request retrieved by the readout signal request detection 
unit to generate a list of the request-saiders, and for 
attaching the list to the corresponduig frame blocks in 
the transmission stand-by buffer, and 

wherein the frame block transmission unit transmits a 
frame block with the request-sender list, and 

wherein the video server further comprises a copy server 
for receiving the frame block with the request-sender 
list, and in response making copies of the frame block 
in a matching number with the request-sender sub- 
scriber interfaces in the request-sender list, and for 
transmitting the copies to the request-sender subscriber 
interfaces in the request-sender list respectively. 

25. The video server of claim 20, wherein the readout 
control unit in each frame block server further includes: 

a table hold unit for holding a table comprising entries, 
each entry showing a correlation between the frame 
blocks and the request-sender subscriber interfaces of 
the readout requests for the frame blocks respectively; 

a fill-out imit for receiving the readout requests and in 
response writing their respective request-sender sub- 
scriber interfaces in the entries; 

a request sender detection unit for detecting any other 
request-sender subscriber mteiface for one frame block 
while referring to the table when the frame block 
transmission unit transnuts the frame block; and 

a copy unit for making copies of the frame block, when 
the request sender detection unit detects other request 
sender subscriber interface, in a matching number of 
the other request-sender subscriber interfaces, and 

wherein the frame block transmission imit transmits the 
frame block copies to the other request-sender sub- 
scribers detected by the request sender detection unit 
respectively. 

26. The video server of claim 20, wherein the readout 
control unit in each frame block server further includes; 

a threshold judgment unit forjudging whether an amount 
of accumulation of each queue has reached a first 
threshold each time the readout request receipt imit 
receives a readout request; 

an excess amount counter for storing an amount exceed- 
ing the threshold for each queue by counting one for the 
excess amount when the threshold judgment unit 
judges that the amount of accumulation exceeds the 
first threshold; 

a queue data storage unit for storing data related to the 
queues that had accumulated the readout requests for 
each frame block stored in the transmission stand-by 
buffer, 

an excess amount judgment tmit for specifying the queues 
corresponding to the frame blocks in the transmission 
stand-by buffer while referring to the queue data stor- 
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age unit, and forjudging whether the excess amount for 
the spedfied queue has counted more than once; 
a higher priority queue judgment unit for detecting a 
queue whose excess amount has been counted once or 
more when the excess amount of the specified queues s 
has not counted; 

a transmission control unit for oontrolliog a firame-block 
transmission in such a way that the frame blocks read 
out by the readout requests stored in the queue detected 
by the higher priority queue judgment are transmitted; 

a dummy request storage unit for storing dummy requests 
when the excess amount judgment unit judges that no 
excess amount has been counted up, the dummy 
request being of a same size as the readout request, and 

wherdn the disk drive discards a dummy request without 
readmg out any frame block when the disk drive 
retrieves the dummy, request 

27. The video server of claim 26, wherein the readout 
control unit in the frame block server further includes: 

a second threshold judgment unit for judging whether an 
amount of accumulation of a queue whose excess 
amount is below a second threshold when the excess 
amount judgment unit judges that the excess amount of 
the queue has not been counted, the second threshold 25 
being smaller than the first threshold, and 

wherein the higher priority queue detection unit retrieves 
the data related to the queue whose amount of accu- 
mulation is judged to be below the second threshold by 
the second threshold judgmem unit 30 

28. TTie video server of claim 26, wherein the readout 
control unit in the frame block server further includes: 

an estimated process time storage unit for storing a time 
required to process all readout requests in each queue 
as an estimated process time; 35 

an estinoation process time computation unit for comput- 
ing an estimated process time for each queue each time 
a readout request is stored in the queue, and for having 
the estimated process time storage unit store the esti- 
mated process time, the estimated process time being ^ 
computed by adding the sum of a time required to read 
out the frame block as per readout request and a time 
required to transmit the frame block, and multiplying 
the sum by the number of the readout requests in the 
queue; 

a threshold judgment unit for judging whether the esti- 
mated process time is below a predetermined threshold 
for the queue whose excess amount is judged as not 
having been counted by the excess amount judgment 
unit, and 

wherein the higher priority queue judgment unit specifies 
the queue whose amount of accumulation is judged to 
be below the threshold by the threshold judgment unit 

29. The video server of claim 28, wherein the readout 55 
control unit in each frame block server further includes an 
estimated process time transmission unit for transmitting the 
estimated process time computed by the estimated process 
time computation unit to the request-sender subscriber inter- 
face each time a readout request is stored in the queue, and ^ 

wherein the readout request transmission unit mciudes a 
transmission control unit for receiving the estimated 
process time transmitted by the estimated process time 
transmission unit for controlling a readout-request 
transmission in such a way that the readout requests are 6S 
transmitted before the predetermined timing based on 
the received estimated process time. 



46 

30. The video server of claim 20, wherein each frame 
block server includes: 

a discard timer for counting a time for the readout request 
each time a readout request is received, a time-out 
occurring when the discard timer counts up a prede- 
tomined vahie; and 

a first discard unit for discarding a frame block read out 
as per a time-out readout request. 

31. The video server of claim 30, wherein each subscriber 
interface includes: 

a return time timer for counting a time between a trans- 
mission of the readout request and a receipt of the 
requested frame block, a time-out occurring when the 
return time counts up a predetermined value; 

a second discard unit for discarding a frame block 
received after time-out occurs in the return time timer 
for the readout request, and 

wherein the time-out is found by a following equation: 

7>nl=Wl-rfll-7W 

where 

Tml is the time-out for the discard timer; 

Tdl is the time-out for die return time timer; 

TelL is a minimum delay time between the transmission of 
the readout request by the readout request transmission 
unit and the transmission of the requested frame block 
by the frame blodc transmission unit; and 

Tbl is a minimimi delay time between the frame block 
transmission by the frame block transmission unit and 
the receipt of the fr-ame block by the firame block output 
unit 

32. The video server of claim 20, wherein the frame block 
server includes: 

a first discarded timer for counting a time for each frame 
block stored in the transmission stand-by buffer, a 
time-out occurs when the first discard timer counts up 
a redetermined value; and 

a frame block discard imit for discarding a time-out frame 
block. 

33. The video server of claim 32, wherein each subscriber 
interface includes: 

a return time timer for counting a time between a trans- 
mission of the readout request and a receipt of the 
requested frame block, a time-out occurring when the 
return time counts up a predetermined value; 

a second discard unit for discarding a frame block 
received after time-out occius in the return time timer 
for the readout request, and 

wherein the time-out is found by a following equation 

where 

Tml is the time-out for the discard timer, 
Tdl is die time-out for the return time timer, 
Tkl is a minimum delay time between the transmission of 
the readout request by the readout request transmission 
unit and the transmission of the requested frame block 
by the frame block transmission unit; and 
Tbl is a minimum delay time between the frame block 
transmission by the frame block transmission imit and 
the receipt of die frame block by the firame block output 
unit 

34. The video server of claim 2, wherein the readout 
control imit includes: 
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a timer for counting a time for each readout request each 
time a readout request is received, a time-out occurring 
when the timer counts up a predetermined value; and 

a transmission control unit for controlling a firame-block 
transmission in such way that the framt blocks are 5 
transmitted when the time-out occurs for the corre- 
sponding readout request 

35. The video server of claim 2, wherein the ATM cell 
switch includes: 

an exchange unit for exdsange the frame blodu and the 

readout requests; 
a passing timing detection unit for detecting timing at 

which the frame blocks and the readout requests pass 

by; 

15 

a passmg time timer for counting a time between a passing 

of the readout request and a passing of the requested 

frame block; and 
a first discard imit for discarding a frame block for which 

the passing time timer has counted a value larger than 20 

a redetermined value. 

36. The video server of claim 35, wherein the passing 
timing detection unit in the AIM cell switch includes: 

a return time timer for counting a time between a trans- 
mission of the readout request and a receipt of the 25 
requested frame block, a time-out occurring when the 
return time timer counts up a predetermined value; and 

a second discard unit for discharging a frame block when 
the frame block is received after the time-out occun in 
the return time timer, and 30 

wherein the predetermined time for the first discard unit 
is found by a following equation: 

TnO^^Tdl-Tfi-Tgi 35 

whm 

Tm2 is the predetermined time for the first discard unit; 
Tdl is the time-out for the return time timer, 
Tfl is a minimum delay time between the transmission of 
the readout request from a subscriber interface and a 
detection of the readout request by the passing timing 
detection unit, 

Tgl is a minimum delay time between a transmission of 45 
the frame block by tiie passing timing detection unit 
and a receipt of the frame block by the subscriber 
interface. 

37. The video server of claim 1, wherein the readout 
requests and the frame blocks are identified by identification 
numbers, and 

wherein the exchange means includes: 
an exchange unit for exchanging the frame blocks and the 

readout requests; 
a passing timing detection unit for detecting timing at 

which the frame block and the readout request pass; 
a frame block identifier detection unit for detecting an 

identification number M of a frame block when tiie 

passing timing detection unit detects a passing of Uie 

frame block; 

a readout request passing monitor unit for detecting an 
identification number M+N of a readout request when 
the passing timing detection unit detects a passing of 
the readout request; 

a passing time timer for counting a time between a passing 
of die readout register identified by the identification 
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number M+N and a passiiig of the frame block iden- 
tified by the identification number M; 

an estimated passing time computation unit for confuting 
a delay time TmJfN Tj between a passing of a readout 
request identified by an identification number M and 
the frame block identified by the identification rmmber 
M, where Tm3 is a counting value of the passing time 
timer, N is a balance between the identific^on number 
of the frame block and the readout request, and 1^ is a 
transmission interval between the readout requests; and 

a first discard unit for discarding the frame block whose 
passing is detected by the frame block identifier detec- 
tion unit when the estimated passing time computed by 
the estimated passing time consumption unit is longer 
than a predetermined time. 

38. The video server of claim 37, wherein tiie passing 
timing detection unit in the ATM cell switch includes: 

a return time timer for counting a time between a trans- 
mission of the readout request and a receipt of the 
requested frame block, a time-out occurring when the 
return time timers counts up a predetermined value; and 

a second discard unit for discarding a frame block when 
the frame block is received after the time-out occurs in 
the retum time timer, and 

wherein the predetermined time for the first discard unit 
is found by a following equation: 

TaOr^Tdi-TJl-Tgl 

where 

Tm2 is the predetermined time for the first discard unit; 
Tdl is the time-out for the retum time timer, 
Tfl is a minimum delay time between the transmission of 
die readout request from a subscriber interface and a 
detection of the readout request by the passing timing 
detection unit, 

Tgl is a minimum delay time between a transmission of 
the frame blod^ by die passing timing detection unit 
and a receipt of the frame block by the subscriber 
interface. 

39. Hie video server of claim 1, wherein the management 
means includes: 

a transmission rate storage unit for storing a transmission 
rate for each piece of digital video data; 

a transmission rate retrieval unit for retrieving the trans- 
mission rate for Uie requested digital video data firom 
the transmission rate storage unit when the manage- 
mem data obtainment unit receives the video request; 

a traffic amount detection unit for detecting a traffic 
amount in the exchange means when the transmission 
rate retrieval unit retrieves the transmission rate; and 

a rejection unit for judging whether die video request 
received by the management data obtainment unit 
should be accepted or rejected based on the transmis- 
sion rate retrieved by the transmission rate retrieval unit 
and the traffic amount detected by the traffic amount 
detection unit, and 

wherein each subscriber interface includes a notice unit 
for oulputting a rejection notice to die request-sender 
subscriber terminal when the rejection unit judges to 
reject the video request 

40. The video server of claim 1, wherein the management 
means further includes a charge uiut for charging each 
subscriber depending on a number of the block pointers 
corresponding to a requested piece of digital video data. 
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41. The video server of claim 1, wherein the exchange 
means is an ATM cell switch for exchange cells, and 

wherein the frame block server includes: 

a transmission stand-by buffer for holding the firame 
blocks in a order of transmission; 

a readout request storage unit for storing a readout request 
of which a requested frame block has been read out and 
stored in the transmission stand-by buffer together with 
conelation widi the frame block; 

a frame block retrieval imit for retrieving the frame blocks 
from the transmission stand-by buffer; 

a request-sender detection unit for detecting a request- 
sender subscriber interface of the readout request for 
the frame block retrieved from the transmission stand- 
by buffer, 

a frame block division unit for dividing the retrieved 
frame block from the transmission stand-by buffer into 
a set of sub-blocks of an equal size; 

a writing unit for writing each sub-block into the data area 
of the cell structure, and writing the request sender 
detected by the request sender detecdon unit into the 
header area of the cell structure; and 

a cell transmission unit for transmitting the cells written 
with the sub-block and the request-sender subscriber 
interface to the request-sender subscriber inteifece. 

42. The video server of claim 41, wherein the &ame block 
transmission unit includes: 

a monitor unit for monitoring an overflow occurring in the 

ATM cell switch; and 
a disallow imit for disallowing the cell transmission unit 

to transmit the cells in case of an overflow, and for 

allowing the cell transmission unit to transmit the cells 

when the overflow is eliminated. 

43. The video server of claim 41, wherein each image 
memory includes a disk array comprising a plurality of disk 
drives, and 

v^^erein the readout control unit further includes a plu- 
rality of queues, each queue being furnished for each 
disk drive respectively, and holding the readout 
requests to read out the firame blocks &om their corre- 
sponding disk drives. 

44. The video server of claim 43, wherein the readout 
request includes an address of each frame block server that 
stores each firame block, and an address of the frame block 
in the frame block server in a corresponding disk array, and 

wherein the readout request is of a cell structure, and each 
subscriber interface writes the address of the firame 
block server in a header area of the cell structure and 
the address of the firame block server in a data area of 
the cell structure. 

45. Tlie video server of claim 8, wherein the number of 
subscribers to whom the video server can supply the digital 
video data must satisfy a following equatiom 



MSB<£X/(pxrt) 

where 

NSB is the mimber of the subscribers who can access to 

the video server simultaneously, 
EX is an exchange ability of the switch means, 
rt is a transmission rate of a cable line interconnecting 

each subscriber interface and each subscriber terminal, 
p is a use firequency per subscriber (times/second). 
46. The video server of claim 45, wherein the tmmber of 
the frame block servers is found by 
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NDB>EXfyr 

where 

NDB is the number of the firame block servers, 

IT is a maximimi retrieval rate of the firame block server. 

47. The video server of claim 46, wherein the number of 
the subscribers who can access to the video server at a time 
is found by 

NACC=^DBx{rr/rt) 

wherein 

NACX; is the number of the subscribers. 

48. The video server of claim 47, wherein a memory 
capacity of each ficame block server can be found by 

MemKDBxNB) 

where 

Mem is the memory capacity of the firame block s^er, 

DB is a data size of one frame block, 

NB is the maximum numb^ of the frame blocks stored in 
one frame block server, and 

wherein the total memory capacity must satisfy an equa- 
tion 



Ment>SmxT>vt/NDB 

where 

Sra is the number of source videos, 

T is a length of a piece of digital video data. 

49. The video server of claim 48, wherein a memory 
capacity of the block buffer in each subscriber interface is 
found by 

where 

B is the memory capacity of the block buffer, 
tr is a time required to transmit the finame blodc from the 
firame block server to the subscriber interface. 

50. A video server which transmits digital video data 
comprising frame blocks having a predetermined sequence 
and stored therein to subscriber terminals as per video 
requests and which can rewrite the digital video data com- 
prising: 

a plurality of firame block servers, each including an 
image memory, a readout control unit for the image 
memory, and a writing control unit for the image 
memory, each image memory storing a plurality of said 
frame blocks nonconsecutive with respect to said pre- 
determined display sequence, the read control unit 
receiving readout requests and in response reading out 
requested firame blocks from the adequate image 
memory, the write control unit receiving a write request 
and in response writing the frame blocks into the image 
memory; 

management means for storing management data speci- 
fying which frame block server stores which frame 
blodc in the image memory and which frame block 
server has a writable area in the image memory, and for 
updating the management data each time a frame block 
is written in the image memory; 

a plurality of subscriber interfaces for receiving the video 
requests firom the subscriber terminals, and in response 
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sending readout requests to frame blodc servers to 
readout frame blocks forming requested digital image 
data in said predetermined sequence while referring to 
the management data, and for transmitting the fra^e 
blocks transmitted fnnn the frame block servers to the 
subscriber terminals at such timing that ensures con- 
tinuous video-play; 

a write interface for obtaining a digital video to divide the 
digital video into a set of sections, and for transmitting 
the divided sections to the firame block servers having 
the writable areas together with the write request, each 
section being of a same size as the frame block; and 

exdiange means for interconnecting each block server, 
each subscriber interface, and each write interface, and 
for transferring the firame blocks read out from the 
frame block servers and transmitted from the write 
interface to the request-sender subscriber interfaces and 
the frame block servers having the writable areas 
respectively. 

51. Ilie video server of claim 50, wherein the manage- 
ment data comprise a plurality of block pointers, each 
identifying a location of each frame block respectively, and 
mcluding an address of each frame block server that stores 
each firame block respectively, and 

wherein each subscriber interface indudes: 
a management data obtainrnent unit for receiving the 
video request from the subscriber terminal, and in 
response retrieving block pointers for the requested 
piece of digital video data from the management 
means; 

a readout request generation unit for generating a readout 
request for each retrieved block pointer addressing to 
the firame block server specified by the address 
included therein; 

a readout request transmission unit for transmitting the 
readout requests to the specified frame block servers, 
one readout request being transmitted at a time; and 

a frame block output unit for receiving the frame blocks 
read out as per the readout requests, and in response 
ou^utting the firame blocks to the request-sender sub- 
scriber terminal at the predetermined timing. 

52. The video server of claim 51, wherein the image 
memory in each firame block server has a memory area 
which is divided into a set of area, each area being suffi- 
ciently large to record one firame block, and 

the management means includes: 

a write pointer storage unit for storing write pointers, each 
write pointer being data showing a correspondence 
between the writable area in the image memory and its 
location; 

a write control data generation unit for retrieving the write 
pointers for each firame block server from the write 
pointer storage unit when the write interface receives 
the write request, and for aligning the retrieved write 
pointers in sequence to generate write control data for 
a piece of digital video data to be recorded; 

a management data conversion unit for converting the 
write control data generated by the write control data 
generation unit into the management data, and 

wherein the write interface includes: 

a management data obtainment unit for receiving the 
write request, and in response retrieving the write 
pointers for the piece of digital video data to be 
recorded from the management means; and 

a write request generation unit for generating a write 
request for each retrieved write pointer addressing to 
the frame block server specified by the write pointer, 
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a division unit for generating a plurality of frame blocks 

by dividing the digital video data; 
a write request transmission unit for transmitting the write 
requests first and then the requested frame blocks to the 

5 specified firame block servos, one of one write request 
and requested firame block being transmitted at a time, 
and wherein each specified frame block serva writes 
die frame block on the writable area in the image 
memory specified by the write request when the write 

IQ request and the firame block are received 

53. ThG video server of claim 52, wherein the exchange 
means is an ATM cell switch for exchanging cells, and 

wherm each image memory is a disk array comprising K 
disk drives for storing the frame blocks, and 

IS wherein each block pointer inchides an address of each 
firame blodc server storing each frame block, and an 
address of the frame block in the disk array, and 
wherein each write pomter includes an address of a firame 
block server storing the corresponding firame block, 

20 and an address of the writable area in the disk array, and 
wherein the readout request is of a cell structure, and the 
readout request transmission unit writes the address of 
the frame block server in a header area of the cell 
structure while writing the address of the frame blodc 

2s in the disk array in a data area of the cell structure to 
generate a readout request for each blodc pointer, and 
the write request transmission unit writes the address of 
the frame block server in the header area while writing 
the address of die writable area in the data area, and 

30 wherein the readout control unit in the frame block server 
detects the address of the frame block in each readout 
request and reads out the requested frame block by 
accessing to the address of &e disk array, and 
wherein the write control unit in the frame block server 

35 detects the address of the frame block in each write 
request and writes the frame block in the writable area. 

54. The video server of claim 53, wherein the disk array 
comprises K disk drives interconnected by a SCSI, and the 
address of the frame block is formatted for a readout 

^ command in a SCSI system, and 

wherein the address of the writable area is formatted for 
a write command in the SCSI system 

55. The video server of claim 53, wherein the readout 
control unit in each firame block server includes: 

K queues for holding the readout requests to read out the 
requested frame blocks firom corresponding disk drives 
in an order of receipt, one queue being furnished for 
one disk drive; 

a readout request recdpt unit for receiving the readout 
requests addressed to the self s frame block server, 

an address analysis unit for detecting the address of the 
requested frame block contained in each readout 
request received by the readout request receipt writ and 
in response specifying the disk <kives to which each 
readout request is addressed using the detected address, 
and for having the queue furnished for the spedfied 
disk drive store the readout request; 

a disk access unit for retrieving one readout request firom 
the K queues, and in response accessing to a memory 

^ area in the specified disk drive at the address contained 
in the readout request to have the disk drive read out the 
requested frame block; 
a transmission stand-by buffer for holding the firame 
blocks read out firom the K disk drives; and 

65 a firame block transmission unit for retrieving the fr^e 
blocks froin the transmission stand-by buffer to trans- 
mit to the request-sender subscriber interface. 
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56. The video server of claim 55, vdierein the write 
control unit includes: 

a write request receipt unit for recdving the write requests 
addressed to the self s tone block saver, 

a frame block receipt unit for receiving the frame blocks 
addressed to the self s frame block server, 

K queues for holding the write requests received by the 
write request receipt unit in an order of receipt, each 
queue being furnished for each disk drive respectively; 

a firame block buffer for holding the frame blocks received 
by the frame block receipt unit; 

an address analysis unit for detecting the address of the 
frame block in each write request received by the write 
request receipt unit, and for specifying the disk drive to 
which each write request is addressed using the 
detected address, and for having the queue furnished 
for the spedfied disk drive store the write request; and 

a readout request judgment umt forjudging whether there 
is any readout request in the queue furnished for the 
disk drive specifieid by the ad(hess analysis unit, and 

wherein each disk drive forming the disk array includes a 
write control unit for writing the frame block as per the 
write request in the frame block buffer on the writable 
area specified by the address in the write request by 
retrieving the write request from the queue when there 
is no readout request in the queue. 

57. The video server of claim 56, wherdn the frame block 
transmission unit includes: 

a readout request storage unit for storing a readout request 
for which a requested frame block has been read out 
and stored in the transmission stand-by buffer together 
with a correlation with the frame block; 

a frame block retrieval unit for retrieving the frame blocks 
from the transmission stand-by buffer, 

a request-sender detection unit for detecting a request- 
sender subscriber interfaces of the readout request for 
the frame block retrieved from the transmission stand- 
by buffer, 

a franie block division unit for dividing the retrieved 
frame block from the transmission stand-by buffer into 
a set of sub-blocks of an equal size; 

a writing unit for writing each sub-block into the data area 
of the cell structure, and writing the request-sender 45 
detected by the request-sender detection unit into the 
header area of the cell structure; and 

a cell transmission uxut for transmitting the cells written 
with the sub-block and the request-sender subscriber 
interface to the request-sender subscriber interface. 

58. The video server of claim 57, wherein the frame block 
transmission unit includes: 

a monitor unit for monitoring an overflow occurring in the 

ATM cell switch; and 
a disallow unit for disallowing the cell transmission unit 

to transmit the cells in case of an overflow, and for 

allowing the cell transmission unit to transmit the cells 

when the overflow is eliminated. 

59. The video server of claim 57, wherein the readout 
control unit in each frame block server includes: 

a delay timer for counting a time for each readout request 
upon receipt- thereof, a time-out occurring when the 
delay timer counts up a redetermined value; and 

a delayed data write unit for writing delay data indicating 
a delay into the cells of a frame block which has been 
read out by a time-out readout request, and 
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wherein the ATM cell switch includes: 

a higher priority queue for storing the cells which have 

delay priority in an order of arrival; 
a lower priority queue for storing the cells which do not 

have the delay priority in an order of arrival; and 
an exchange control unit for controlling a cell exchange in 

such a way that the cells in the higher priority queue are 

transmitted first, and then the cells in the lower priority 

queue are transmitted. 

60. A video server which transmits digital video data 
corr^msing firame blocks having a predetermined sequence 
and stored ±erein to subscriber terminals as per video 
requests comprising: 

a plurality of frame block servers, each including an 
image memory and a readout control unit for the image 
memory, each image memory storing a plurality of said 
frame blocks nonconsecutive with respect to said pre- 
determined display sequence, the readout control unit 
receiving readout requests and in response reading out 
requested frame blobks from the image memory; 

management means for storing* management data sped- . 
fying which frame block server stores which frame 
block in the image memory; 

a plurahty of subscriber interfaces for receiving the video 
requests from the subscriber terminals, and in response 
sending readout requests to the firame block servers to 
readout the firame blocks forming requested digital 
image data in said predaermined sequence while refer- 
ring to the management data, and for transmitting the 
frame blocks transmitted finom the frame block servers 
to the subscriber terminals at such timing that ensures 
continuous play, each subscriber interface being con- 
nected to a plinality of terminals; and 

exchange means for interconnecting each block server 
and each subscriber interface to transfer the frame 
blocks read out from the firame block servers as per the 
readout requests to the request-sender subscriber inter- 
faces. 

61. The video server of claim 60, wherein the manage- 
ment data comprise a plurality of block pointers, each 
identifying a location of each firame block respectively, and 
including an address of each frame block server that stores 
each firame block respectively, and 

wherein eadi subscriber interface includes: 
a management data obtairunent unit for receiving the 
video request from the subscriber terminal, and in 
response retrieving block pointers for the requested 
piece of digital video data from the management 
means; 

a readout request generation unit for generating a readout 
request for each retrieved block pointer addressing to 
the frame block server specified by the address 
included therein; 

a readout request transmission unit for transmitting the 
readout requests to the specified frame block servers, 
one readout request bdng transmitted at a time; and 

a frame block output unit for receiving the frame blocks 
read out as per the readout requests, and in response 
outputting the frame blocks to the request-sender sub- 
scriber terminal at predetermined timing. 

62. The video server of claim 61, wherein each subscriber 
interface is connected to a plurality of subscriber terminals, 
each subscriber terminal outputting a video request includ- 
ing a terminal identifier, and 

wherein the management data obtainment unit further 
includes an identifier detection unit for detecting the 
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terminal identifiers contained in the video requests sent 
horn the subscriber terminals upon receipt thereof, and 
wherein the readout request transmission unit further 
includes an identifier attachment unit for attaching the 
terminal identifiers detected by the identifier detection 
unit to each readout request generated by the readout 
request generation unit, and 

wherein the readout control unit in each fiame block 
server includes: 

a readout request receipt unit for detecting die terminal 
identifiers when receiving the readout requests ftom the 
readout request transmission unit; and 

a frame block transmission unit for attaching the terminal 
identifiers detected by the readout request receipt unit 
to each request frame block read out as per the readout 
requests before the transmission th^eof to the request- 
sender subscriber interface, and 

wherein the frame block output unit further includes a 
distribution output control unit for receiving the termi- 
nal-identifier-altached frame blocks and in response 
outputting the same to the request-sender subscriber 
terminal identified by the terminal identifier. 

63. The video server of claim 62, wherein the frame block 
output unit includes: 

a frame block receipt unit for receiving the frame blocks 
addressed to the self s subscriber interface and attached 
with the terminal identifier; 

a block buffer for accumulating a certain number of frame 
blocks received by the frame block receipt unit; 

an accumulated amount judgment unit for judging 
whether the block buffer stores more than a predeter- 
mined number of frame blocks; and 

an output unit for ou^utting the certain number of the 
frame blocks accumulated in the block buffer when the 
accumulated amount judgment unit judges that the 
block buffer stores more than the predetermined num- 
ber of frame blocks, one frame block being outputted at 
a time to the request-sender subsmber terminal. 

64. TTie video server of claim 63, wherein the frame block 
output unit further inchides a check unit for checking an 
ovCTflow and an underflow occurring at the block buffer, and 

wherein the readout request transmission unit includes a 
transmission control unit for controlling a readout- 
request transmission in such a way that the readout 
request are transmitted after the predetermined timing 
upon detection of the overflow by the check unit, and 
before the predetermined timing upon detection of the 
underflow by the check unit 

65. "nie video serve of claim 62, wherein the exchange 50 
means is an ATM cell switch for exchanging cells, and 

wherein each image memory is a disk array comprising K 
disk drives for storing the frame blocks, and 

wherein each block pointo: includes an address of each 
firame block server storing each frame block, and an 
address of the frame block in the disk array, and 

wherein the readout request is of a cell structure, and the 
readout request transmission imit writes the address of 
the frame block server in a header area of the cell 
structure while writing the address of the frame block 
in the disk array in a data area of the cell structure to 
generate a readout request for each block pointer, and 

wherein the readout control unit in the frame block server 
detects the address of the frame block in each readout 
request and reads out the requested frame block by 
accessing to the address of the disk array. 
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66. The video server of claim 65, wherein the disk array 
conq)rises K disk drive interconnected by a SCSI, and the 
address of the frame block is formatted for a readout 
command in a SCSI system. 

67. TTie video server of claim 65, wherein the readout 
control unit in each frame block server includes: 

K queues for holding the readout requests to read out the 
requested frame blocks from corresponding disk drives 
in an order of receipt, one queue being furnished for 
one disk drive; 

an address analysis unit for detecting the address of the 
requested frame block contained in each readout 
request received by the readout request receipt unit and 
in response specifying the disk (hives to which each 
readout request is addressed using the detected address, 
and for having the queue furnished for the specified 
disk drive store the readout request; 

a disk access unit for retrieving one readout request from 
the K queue, and in response accessing to a memory 
area in the specified disk drive at the address contained 
in the readout request to have the disk drive read out the 
requested frame block; 

a transmission stand-by buffer for holding the frame 
blocks read out firom the K disk drives; and 

a frame block transmission unit for retrieving the frame 
blocks from the transmission stand-by buffer, and for 
attaching the terminal identifier to the retrieved frame 
block to transmit to the request-sender subscriber inter- 
face. 

68. The video server of claim 67, wherein the frame block 
transmission unit includes: 

a readout request storage unit for storing a readout request 
for which a requested frame block has been read out 
and stored in the transmission stand-by buffer together 
with a correlation with the frame block; 

a frame block retrieval unit for retrieving the frame blocks 
from the transmission stand-by buffer; 

a request-sender detection unit for detecting a request- 
sender subscriber interface of the readout request for 
the frame block retrieved from the transmission stand- 
by buffer; 

an identifier attachment unit for attaching the terminal 
identifier in the retrieved readout request detected by 
the readout receipt unit to the requested frame block; 

a frame block division unit for dividing the retrieved 
frame block attached with the terminal identifier from 
the transmission stand-by buffer into a set of sub-blocks 
of an equal size; 

a writing unit for writing each sub-block into the data area 
of the cell structure, and writing the request-sender 
detected by the request-sender detection unit into the 
header area of the cell structure; and 

a cell transmission unit for transmitting the cells written 
with the sub-blocks and the request-sender subscriber 
interface to the request-sender subscriber interface. 

69. The video server of claim 68, wherein the frame block 
transmission unit includes: 

a monitor unit for monitoring an ovctA ow occurring in the 

ATM cell switch; and 
a disallow unit for disallowing the cell transmission unit 

to transmit the cells in case of an overflow, and for 

allowing the cell transmission unit to transmit the cells 

when the overflow is eliminated. 

70. The video server of claim 68, wherem the readout 
control unit in each frame block server includes: 
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a delay timer for counting a time for each readout request 
upon receipt thereof, a time-out occurring when the 
delay tim^ counts up a redetermined value; and 

a delayed data write unit for writing delay data indicating 
a delay into the cells of a frame block which has been 5 
read out by a time-out readout request, and 

wherein the ATM cell switch includes: 

a higher priority queue for storing the cells which have 
delay priority in an order of arrival; 

a lower priority queue for storing the cells which do not 
have the delay priority in an order of arrival; and 

an exchange control unit for controlling a cell exchange in 
such a way that the cells in the higher priority queue are 
transmitted first, and then the cells in the lower priority 
queue are transmitted. 

71. The video server of claim 61, wherein the readout 
request transmission unit includes: 

a most recent transmission time storage unit for storing a 
transmission time when a readout request is transmitted 
most recently; ^ 

a transmission judgment unit for judging whether a read- 
out request is being transmitted for another subscriber 
when the management data obtainment unit receives a 
video request from one subscriber; 

a time control unit for controlling a readout-request ^ 
transmission for one subscriber while the readout 
request for another subscriber is being transmitted in 
such a way that a first readout request for the video 
request firom the former subscriber is transmitted after 
a certain interval from the most recent transmission 30 
time, and that a second and subsequent readout requests 
are transmitted at predetennined issuance intervals 
from the transmission of the first readout request, the 
certain interval being found by multiplying a mean 
frame-block transmission rate of the plurality of sub- 35 
scriber interfaces in transmitting the frame blocks to the 
request-sender subscriber terminals by the number of 
the connected subscriber terminals, and dividing an 
amount of data of one frame block by the resulting 
value, the predetermined issuance interval being found 40 
by dividing the frame-block data amount by the trans- 
mission rate of one frame block. 

72. The video server of claim 61, wherein the readout 
request transmission unit includes: 

a transmission schedule generation unit for making out a 
transmission schedule of each readout request for a 
video requests upon receipt thereof by the management 
data obtaiimient unit; 

a clock unit for showing a current time; 

a transnoission time buffer for storing a next scheduled 
time, the next scheduled time being a scheduled time 
nearest to the current time; 

a transmission control unit for controlling a readout- 
request transmission in such a way that a readout 55 
request scheduled for the next scheduled time is trans- 
mitted when the clock unit shows the next scheduled 
time; 

a transmission scheduled time determination unit for 
determining the transmission schedule, when the man- 60 
agement data obtairmient unit receives a video request 
from anotiier subscriber, by setting the transmission 
scheduled time for a first readout request after a pre- 
determined interval from the next scheduled time, and 
by setting scheduled times for second and subsequent 6S 
readout requests at predeteniuned issuance intervals 
from the scheduled time for the first readout request; 
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a schedule write unit for writing the transmission sched- 
uled times determined by the transmission scheduled 
time determination unit into the transmission schedule, 
the certain interval being found by multiplying a mean 
frame-block transmission rate of the plurality of sub- 
scriber interfaces in transmitting the frame-blocks to 
the request-sender subscriber terminals by the number 
of the coimected subscriber terminals, and dividing an 
amount of data of one frame block by the resulting 
value, the predetennined issuance interval being found 
by dividing the frame-block data amount by the trans- 
mission rate of one frame block. 

73. A video server which transmits digital video data 
comprising frame blocks having a predetennined sequence 
and stored thmin to subscriber terminals as per video 
requests comprising: 

a plurality of firame block servers, eadi including an 
image memory and a readout control unit for the image 
memory, each image memory storing a plurality of said 
frame blocks nonconsecutive with respect to said pre- 
determined display sequence, the readout control unit 
receiving readout requests and in response reading out 
requested frame blocks from the image memory; 

management means for storing management data speci- 
fying which frame block server stores which frame 
block in the image memory; 

a plurality of subscriber interfaces for receiving the video 
requests from the subscriber terminals, and in response 
sending readout requests to die frame block servers to 
readout the frame blocks forming requested digital 
image data in said predetermined sequence while refer- 
ring to the nmnagement data, and for transmitting the 
frame blocks transmitted from the firame block servers 
to the subscriber terminals at such timing that ensures 
a continuous play; and 

an exchange network including a plurality of exchange 
units interconnected to each other, each being selec- 
tively connected to a plurality of frame block servers 
and a plurality of subscriber interfaces for transferring 
the frame blocks addressed to the self s fi:ame block 
server to the request-sender subscriber interfaces 
respectively. 

74. TTie video server of claim 73, wherein the manage- 
ment data comprises a plurality of block pointers, each 
identifying a location of each frame block respectively, and 
including an address of each frame block server that stores 
each frame block respectively, and 

wherein each subscriber interface includes: 
a management data obtairunent unit for receiving the 
video request from the subscriber terminal, and in 
response retrieving block pointers for the requested 
piece of digital video data from the management 
means; 

a readout request generation unit for generating a readout 
request for each retrieved block pointer addressing to 
the frame block server specified by the address 
included therein; 

a readout request transmission unit for transmitting the 
readout requests to the specified frame block servers, 
one readout request being transmitted at a time; and 

a frame block output unit for receiving the frame blocks 
read out as per the readout requests, and in response 
outputting the frame blocks to the request-sender sub- 
scriber terminal at predetermined timing. 

75. The video server of daim 74, wherein the exchange 
network is an ATM cell switch for transferring the cells, and 
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wherein each unage memory is a disk array comprising K 
disk drives for storing the frame blocl^, and 

wherein each block pointer includes an address of each 
frame block server storing each frame block, and an 
address of the frame block in the disk anay, and 

wherein the readout request is of a cell strucmre, and the 
readout request transmission unit writes the address of 
the &am£ block server in a header area of the cell 
structure while writing the address of the frame block 
in the disk array in a data area of the cell stmcture to 
generate a readout request for each block pointer, and 

wherein the readout control unit in the frame block server 
detects the address of the frame block in each readout 
request and reads out the requested frame block by 
accessing to the address of the disk array. 

76. The video server of claim 75, wherein the disk array 
comprises K disk drives interconnected by a SCSI, and the 
address of the fr^me block is formatted for a readout 
command in a SCSI system. 

77. The video server of claim 75, wherein the readout 
control unit in each fr^me block server includes: 

K queues for holding the readout requests to read out the 
requested frame blocks from corresponding disk drives 
in an order of receipt, one queue being fiimished for 
one disk drive; 

a readout request receipt unit for receiving the readout 
requests addressed to the self s frame block server, 

an address analysis unit for detecting the address of the 
requested frame block contained in each readout 
request received by the readout request receipt unit and 
in response specifying the disk drives to which each 
readout request is addressed using the detected address, 
and for having the queue furnished for the specified 
disk drive store the readout request; 

a disk access unit for retrieving one readout request from 
the K queues, and in response accessing to a memory 
area in the specified disk drive at the address contained 
in the readout request to have the disk drive read out the 
requested frame block; 

a transmission stand-by buffer for holding the frame 
blocks read out from the K disk drives; and 

a frame block transmission unit for retrieving the frame 
blocks from the transmission stand-by buffer to trans- 
mit to the request-sender subscriber interface. 

78. The video server of claim 77, wherein the fimoe block 45 
transmission unit includes: 

a readout request storage unit for storing a readout request 
for which a requested frame block has been read out 
and stored in the transmission stand-by buffer together 
with a correlation with the frame block; 

a frame block retrieval unit for retrieving the frame blocks 
from the transmission stand-by buffer; 

a request-sender detection unit for detecting a request- 
sender subscriber interface of the readout request for 
the frame block retrieved from the transmission stand- 
by buffer, 

a frame block division unit for dividing the retrieved 
frame block from the transmission stand-by user into a 
set of sub-blocks of an equal size; 

a wridng unit for writing each sub-block into the data area 
of the cell structure, and writing the request-sender 
detected by the request-sender detection unit into the 
header area of the cell structure; and 

a cell transmission unit for transmitting the cells written 65 
with the sub-block and the request-sender subscriber 
interface to the request-sender subscriber interface. 
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79. Hie video server of claim 78, wherein the frame block 
transmission unit includes: 

a monitor unit for monitoring an overflow occurring in the 

ATM cell switch; and 
a disallow unit for disallowing the cell transmission unit 

to transmit the cells in case of an overflow, and for 

allowing the cell transmission unit to transmit the cells 

when the overflow is eliminated. 

80. A method for storing and distributing a plurality of 
video data to a plurality of clients in response to video 
requests made by said clients comprising; 

dividing each video into a plurality of disaete video 
segments and storing said video segments in a plurality 
of video segment file servers; 

recording the location of each video segment and the 
intended sequence of each video segment in a control 
file, and storing each control file in a system manager, 

providing a client interface which is connected to a 
plurality of client terminals for receiving client requests 
and communicating a readout request corresponding to 
said client request to a video file sequence manager; 

communicating the control file of the video data corre- 
sponding to each readout request from said system 
manager to said video file sequence manager; 

retrieving the video segments from the video segment file 
servers to the video file sequence manager according to 
said control file of the video data; 

transmitting each video segment retrieved by said video 
file sequence manager to said client intei&ce in a 
predetermined sequence profile specified by said con- 
trol file and coordinated to achieve a continuous trans- 
mission of said video data; and 

transmitting said continuous transmission of said video 
data from said client interface to said client. 

81. The method for storing and transmitting video data as 
recited in claim 80 further including the step of monitoring 
the amount of video segments arriving at said video file 
sequence manager and temporarily storing said video seg- 
ments in a buffer when an overflow occurs, and retrievmg 
said video segments from said buffer into said video file 
sequence manager when said overflow has expired. 

82. The method for storing and transmitting video data as 
recited in claim 81 further including the step of assigning 
priority to video segments having a shorter retrieval time to 
be transmitted by said video file sequence manager to said 
client interface whereby the continuous transmission of said 
video data is maintained. 

83. The method for storing and transmitting video data as 
recited in claim 81 wherein the step of dividing the video 
data into video segments is performed to distribute an 
approximately equal number of video segments in each 
video segment file server. 

84. A video storage and distribution system for accessing 
and transmitting video data to a plurality of subscribers 
according to submitted requests by said subscribers, said 
system designed to transmit a requested video data to 
multiple subscribers using a plurality of video storage units 
load balanced to operate at generally identical delivery 
loads, each said requested video data comprised of discrete 
video segments stored substantially equally among the plu- 
rality of video storage units, said system comprising: 

a plurality of subscriber terminal means for transmitting 
subscriber requests for video data; 

a subscriber interface connected to said plurality of sub- 
scriber terminal means adapted to receive said request 
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for video data ainl generate a readout command for said 
requested video data; 

a system control unit comprising sequence information 
and address information corresponding to said 
requested video data; ^ 

a plurality of video storage units comprising readout 
conunand receiving means for receiving one of said 
readout commands generated by said subscriber inter- 
face, video segment storage means for storing a plu- 
rality discrete video segment data corresponding to 
incccments of said requested video data according to 
said address information, and video segment data 
retrieval means for retrieving said video segment data 
corresponding to said readout command; and 

an exchange unit connected to each of said plurality of 
video storage units, said subscriber interface, and said 
system control unit, said exchange unit receiving said 
readout command &om said subscriber interface and 
retrieving said sequence information and address infor- ^ 
mation corresponding to said requested video data from 
said system control unit and submitting readout com- 
mands to the video storage unit corresponding with 
each video segment of said requested video data as 
determined by the address information and sequence ^5 
information, said exchange unit thereafter receiving 
said video segment data retrieved by said video seg- 
ment data retrieval means of said video storage unit, 
and said exchange unit thereaftCT transmitting said 
video segment data sequentially to said subscriber ^ 
interface for continuous delivery to said subscriber 
terminal. 

85. A method for transmitdng a video image sequence of 
a predetermined duration concurrently to a pli^ity of 
dients in response to requests by said clients comprising: 

dividing said video image sequence into a plurality of 
discrete video segments; 

distributing said discrete video segments among a plural- 
ity of video segment storage units; 

storing a storage address for each discrete video segment ^ 
in a control unit, and storing a predetermined sequence 
data of said video segments in said control unit; 

receiving a first request for said video image sequence 
from a first client; 

45 

transmitting said first request to a data exchange umt, 
which retrieves said sequence data and sends a request 
to the address of said video segment corresponding to 
said first video segment of said sequence data, and after 
receiving same transmitting said first video segment to ^ 
said first user according to a predetermined schedule; 

receiving a second request for said video image sequence 
from a second client; 

transmitting said second request to said data exchange, 
which retrieves said sequence data and sends a request 
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to the address of said video segment corresponding to 
said first video segment, and after receiving same 
transmitting said first video segment to said second user 
according to a predetermined schedule; and 
locatiiig and retrieving each successive video segmrat and 
transmitting each video segment to eadi requesting 
client according to said retrieved sequence and a pre- 
determined schedule. 
86. A syst^ for storing, retrieving, and delivering a 
plurality of audio visual works such as feature lengdi movies 
to a plurality of requesting clients, each audio-visual work 
being deliverable to a plurality of clients concurrently and 
delivery of said audio-visual work to each of said clients is 
independent of delivery of said audio-visual work to all 
other clients, said system comprising: 
a plurality of video storage servers each comprising a 
computer interface and video data storage means for 
storing a plurality of video data blocks, each said video 
data block contairung video data corresponding to a 
segment of one of said plurality of audio-visual works 
such that when each video data block corresponding to 
one of said audio-visual works is delivered continu- 
ously in a predetermined sequence said audio-visual 
work is reproduced, said video data blocks stored in 
said video storage servers such that no video storage 
server stores two sequential video data blocks of a 
given audio- visual work; 
a sequence storage means for storing sequence informa- 
tion for each audio-visual work and for transmitting 
said sequence information, said sequence information 
conq}rising the predetermined sequence of the video 
data blocks and video storage server storing each video 
block; 

a plurality of sequence control brok^ connected to a 
plurality of clients, said sequence control brokers 
adapted to receive a video request for an audio- visual 
work firom said client and generate a readout command 
for said video request, and fiirther adapted to receive 
video data and transmit said video data to said client; 
and 

a control unit connected to each of said plurality of 
sequence control brokers, said sequence storage means, 
and each of said video storage servers, said control unit 
adapted to receive said readout commands generated 
&om said control brokers, retrieve the sequence infor- 
mation for the video request corresponding to said 
readout request, retrieve the video data sequentially 
from the plurality of video data servers for the atidio- 
visual work according to said sequence information, 
and transmit the video data sequentially to the sequence 
control brokers such that an uninterrupted delivery of 
said audio-visual work to said client is achieved. 

^ « « « 9^ 
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[57] ABSTRACT 
A multiple processor (CPU) computer system, each 
CPU having a separate, local, random access memory 
means to which it has direct access. An interprocessor 
bus couples the CPUs to memories of all the CPUs, so 
that each CPU can access both its own local memory 
means and the local memories of the other CPUs. A run 
queue data structure holds a separate run queue for each 
of the CPUs. Whenever a new process is created, one of 
the CPUs is assigned as its home site and the new pro- 
cess is installed in the local memory for the home site. 
When a specified process needs to be transferred from 
its home site to another CPU, typically for performing 
a task which cannot be performed on the home site, the 
system executes a cross processor call, which performs 
the steps of: (a) placing the specified process on the run 
queue of the other CPU; (b) continuing the execution of 
the specified process on the other CPU, using the local 
memory for the specified process's home site as the 
resident memory for the process and using the interpro- 
cessor bus to couple the other CPU to the home site's 
local memory, until a predefmcd set of tasks has been 
completed; and then (c) placing the specified process on 
the run queue of the specified process's home site, so 
that execution of the process will resume on the pro- 
cess's home site. 

13 Claims, 6 Drawing Sheets 
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PROCESS DISTRIBUTION AND SHARING 
SYSTEM FOR MULTIPLE PROCESSOR 
COMPUTER SYSTEM 

5 

This is a continuatioa of application Ser. No. 907,568 
filed SepL 15, 1986, now abandoned 

The present mvention relates generally to multiple 
processor compoter systems, and particularly to appara- 
tus and methods for moving a process from one site to 10 
another within a multiple processor computer system. 

BACKGROUND OF THE INVENTION 
The prior art includes a large number of different 
multiple processor computer systems, and a number of 15 
variations on the UNIX (a trademark of AT&T) operat- 
ing system. 

For the purposes of this introduction, multiple pro- 
cessor computer systems can be generally classified into 
two distinct types: (1) those that perform complex cal- 20 
culatioos by allocating portions of the calculation to 
different processors; and (2) those that are enhanced 
multitasking systems in which numerous processes are 
performed simultaneously, or virtually simultaneously, 
with each process being assigned to and performed on 25 
an assigned processor. The present invention concerns 
the second type of multiple processor system. 

In order to avoid concision between the terms "pro- 
cessor** (which is a piece of apparatus including a cen- 
tral processing unit) and "process" (which is a task 30 
being performed by a computer), the terms "site" and 
"CPU" shall be used herein synonymously with "pro- 
cessor". For instance, when a process is created, it is 
assigned to a particular site fi.e., processor) for execu- 
tion. 35 

As background, it should be understood that in any 
multitasking system, there is a "run queue" which is a 
list of all the processes which are waiting to run. In most 
systems the run queue is a linked list When the system 
is done with one process (at least temporarily) and 40 
ready to start running another process, the system looks 
through the run queue and selects the process with the 
highest priority. This process is removed from the run 
queue and is run by the system until some event causes 
the system to stop the selected process and to start 45 
running another process. 

In prior art multiple processor (also called multiple 
CPU) systems, there is generally a single large memory 
and a single run queue for all of the processors in the 
system. While the use of a single run queue is not inher- 50 
ently bad, the use of a single large memory tends to 
cause increasing memory bus contention as the number 
of CPUs in the system is increased. 

Another problem associated with most multiple CPU 
computer systems, only one of the CPUs can perform 55 
certain tasks and functions, such as disk access. There- 
fore if a process needs to perform a particular function, 
but is running at a site which cannot perform that func- 
tion, the computer system needs to provide a method 
for that process to perform the function at an appropri- 60 
ate site within the system. 

Generally, the problems associated with such "cross 
processor calls" include (1) minimizing the amount of 
information which is moved or copied from one site to 
another each time a process makes a cross processor 65 
call; (2) devising a method of updating the system*s run 
queue(s) which prevents two processors from simulta- 
neously changing the same run queue, because this 
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could produce unreliable results; and (3) providing a 
method for efficiently transferring a process to a an- 
other site and, usually, then automatically transferring 
the process back to its original site. 

The present invention solves the primary memory 
contention and cross processor call problems associated 
with prior art multiple CPU systems by providing a 
separate local memory and a separate run queue for 
each processor. Memory contention b minimized be- 
cause most processes are run using local memory. When 
a process needs to be transferred to a specified proces- 
sor a cross processor routine simply puts the process on 
the run queue of the specified CPU. The resident mem- 
ory for the process remains in the local memory for the 
process's home CPU. and the specified CPU continues 
execution of the process using the memory in the home 
CPU. The process is transferred back to its home CPU 
as soon as the tasks it needed to perform on the specified 
CPU are completed. 

It is therefore a primary object of the present inven- 
tion to provide an improved multiple CPU computer 
system. 

Another object of the present invention is to provide 
an efficient system for transferring processes from one 
CPU to another in a multiple CPU computer system. 

SUMMARY OF THE INVENTION 

In sunamary, the present invention is a multiple pro- 
cessor (CPU) computer system, each CPU having a 
separate, local, random access memory means to which 
it has direct access. An interprocessor bus couples the 
CPUs to memories of all the CPUs, so that each CPU 
can access both its own local memory means and the 
memory means of the other CPUs. A run queue data 
structure holds a separate run queue for each of the 
CPUs. 

Whenever a new process is created, one of the CPUs 
is assigned as its home site and the new process is in- 
stalled in the local memory means for the home site. 
When a specified process needs to be transferred from 
its home site to another CPU, typically for performing 
a task which cannot be performed on the home site» the 
system executes a cross processor call, which performs 
the steps of: (a) placing the specified process on the run 
queue of the other CPU; (b) continuing the execution of 
the specified process on the other CPU, using the mem- 
ory means for the specified process's home site as the 
resident memory for the process and using the interpro- 
cessor bus means to couple the other CPU to the home 
site memory means, until a predefmed set of tasks has 
been completed; and then (c) placing the specified pro- 
cess on the run queue of the specified process's home 
site, so that execution of the process will resume on the 
process's home site. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Additional objects and features of the invention will 
be more readily apparent from the following detailed 
description and appended claims when taken in con- 
junction with the drawings, in which: 

FIG. 1 is a block diagram of a multiprocessor com- 
puter system, and some of its most important data struc- 
tures, in accordance with the present invention. 

FIGS. 2A and 2B schematically represent the cross 
processor call procedure of the preferred embodiment 

FIG. 3 is a block diagram of the CPUSTATE data 
structure used in the preferred embodiment of the pres- 
ent invention. 
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FIG 4 is a flow chart^of the piocess by which a insertion of a cross processor call to ^ routines 

J^:^:£l^yc^^'^^-o^ -rjp^^^^S^^r^r^llsare 

Cram one site to another m a wnnputer systeni. -erfonnrf only to have a system request serviced 

FIG. 5 is a flow ^of .«=°«fVrS^^ 5 ^^^bc «rviced at Sehome dte of the pro- 

n,ctbodusedinthep.efenedenibo«tan«t ofthem^^ 5 ^^^^ ^ schematically represent the 

tion to move a process from one srte to another m a ^ J^^^ ^ procedure of the preferred embodi- 

computer system* ' ^ ' . 

FIO. 6 is a flow chart of the ^ETRQ ""^ to HG. 2A, the process identified as Proc 

which is used by the context switching method dia- ,^ have a home site on an appUcations pro- 

gramed in FIG. 4. . . ^ m^ssar Tlc. not the main processor) and to be running 

HG-Tisaflowclu^ ofthemethodusedforcrea^^ ^^hm^fT?^^ rJuntU a system rou- 

a new process and asagmng it a home ate. tine fe caUed (box 50). If the system routine can be run 

Fia 8 is a block diagram of a virtual in^^ry man- ^ ^^^^^ ^ply 

agement page table used m the preferred embodunent of ^ process continues to run on the home 

the present inventioa. 5qj 

DESCRIPTION OF THE PREFERRED If, however, the system routine cannot be run locally 

EMBODIMENT (box 52), then the process is put on the main processor's 

^, , nm queue (box 56), where it waits until the main proces- 

Refening to FIG. t there is shown a block diagram ^ execution (box 58). Then the 

of a multiprocessor computer system 20, and some of its resumes running on the MP, where it runs tiie 

most important data structures, in accordance with the system routine. 

present invention. In a typical configuration, the system system routine completes the tasks which 

20 includes a main processor MP, and a plurality n of ^ performed by the MP, the process is put back 

application processors API to APn. ^5 on tiie home atc's run queue (box 62), where it waits 

All of the system's processors are homogeneous, ^ j^^^jj^^ ^py ^ ^^^^ up (box 64) and 

separate one-board microcomputers using a Motorola continue execution of the process (box 50). 

68020 central processing unit For convenience, these Looking at this same process from another perspec- 

processon are also called "CPUs" and "sites'*. ^^^^ pjQ 2B at time zero process PI is running on 

The system 20 is a multitasking computer system processor AP and process P3 is running on the main 

which typically has a multiplicity of processes, also processor MP. At time tl process PI performs a system 

called •'user processes" or "tasks", running and waiting ^ ^^^^ a system routine) which requires pro- 
to run. As will be described in greater detail below, 

cessing on the MP. Therefore, shortly after the system 

each user process is assigned a "home site" or "home tim g t2. Pi's context is saved (in its user struc- 

processor" when it is created. 35 ture) and PI is put on MP's run queue. It should be 

^ noted that PI is usually given a high priority when it 

Cross Processor Calls performs a cross processor call so that its request will be 

The present invention provides a simple system for serviced quickly. Also, when the AP stops running PI it 

temporarily moving a user process away from its home picks up another process P2 from its run queue and runs 

site to a specified remote site. To do this, the sute of the 40 that process. 

process is saved Oust as it would be saved whenever the MP continues to run process P3 until some event 

process is suspended in any other multitasking system), blocks or interrupts P3's execution at time t3, at which 

and then a pointer to the user process is snnply added to point the MP will run PU At time t4, when PI fmishcs 

the remote site's "run queue" and removed from the list the system tasks which required the use of the main 

of processes running on tiie home site. 45 processor MP. Pi's context is saved and it is put back on 

When the remote site picks up this user process from the run queue for its home site, AP. At thi? point the 

its run queue, it merely reinstates the process and runs m? picks up the highest priority process from its run 

the process just like any other process. After the task queue, which may be the process P3 that was inter- 

which required the cross processor call is completed, rupted by PI. 

the interprocessor transfer is reversed by saving the 50 AP continues to run process P2 until some event 

user process's state and adding a pointer to the user blocks or interrupts P2's execution at time tS, at which 

process to the run queue for its home site. point the AP wUl pick up the highest priority process 

The system's memory is organized so that the remote from its run queue, which may be the process PI. 

site can use the user process's memory at its home site. Memory 

rather than moving the process's resident memory to 55 

the remote site. Referring again to FIG. 1. each CPU has its own 

There are several advantages to this approach. The memory module MEM— MP. and MEMl to MEMn. 

first is that the context which requires a user process to which is used as the primary random access memory for 

be moved away from its home site need not be copied its corresponding CPU. 

into a message encapsulating the request, and all refer- 60 The resident memory for each user process m the 

ences to parameters needed by the process can be made system is located in the memory module for its home 

directly to the process's resident memory at the home site. 

site. Secondly, there is no need to synchronize one While each CPU has its own memory module, these 

processor with any other. Third, the cross processor memory modules are multiported and conneaed to at 

caU is virtuaUy transparent to tiic system and requires 65 least one bus so that all physical memory in die system 

very lilde ovcrficad and mmimal modification of the can be accessed by any processor in the system. That is. 

system's operating system. In most instances, the only all of tiie system's physical memory resides m a single, 

modification to the operating system required is the large physical address space. Also, any given processor 
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can we the i«ge tables describing the virtual memory of Interprocessor Busses 

"L^t'S'rfSis memory organization, any user Another difference between tte n«un process Kff 

pro«ifaS.ystemc«iexe««e<ia^ofthe$y8tem's and the appUcations processors API to APn « that to 
^TSough the user pr^'s resident J .nain proceaor hjs different mterprocessor bus comiec- 

located on^y one prcLsor (the home -'ZX^^^^^'^^r u 

, , - . ^ r^J^ and 26. One, called the system composition bus 24, can 

Smce access to local memory Cc., access by a CPU between processors at a rate of 12 mega- 

to its own memory module) is much faster than cross- MB/secX The other bus, called the 

processor memory access, the system is designed to run interprocessor bus 26, can transfer data between proces- 

a process as much as possible on its home processor, and 33 3 j^/sec. The provision of two such busses 

to move its execution to another processor only when allows the faster bus to handle video tasks and other 

necessary. Normally, a process's execution b moved ^ ^^ich require hi^ data rates, while the slower bus 

away from its home site only to have a system request handles interprocessor memory requests between the 

serviced which cannot be serviced at the home site. nuun processor and one of the applkatioos processors. 

The main processor's memory module MEM_MP All of the applications processors, API to APn and 

holds a number of important data structures including a the system's Display Processor 28 are connected to both 

Process Table 30 which holds essential data regarding busses 24 and 26. The main processor MP is not con- 
each of the processes in the system, a CPUSTATE data 20 nccted to the faster bus mosdy to avoid the cost of 

structure which contains important data on the status of adding another high speed port to the main processor, 

the processor, and a set of USER data structures which which b already burdened with the disk controUer and 

hold data relating to the state of each process allocated two terminal ports (not shown in the Figures). 

to the main processor. Indivisible Rcad-Modify-Writc Instructions 

Each processor has a CPUSTATE data structure, ^5 ^ , 

which is stored in its local memory. Each processor^ As wdl be explamed m more detad bel^^^^ 

local memory also has an array of USER data struc- sors in the system must be able to p^^ 

7." ^ , ^ , , , ,oi«fi«« fK« «rrL. the "mdivisible read-modify-wnte mstrucdons" known 
tures. which are used to hold data relating to the pro- or compare and swap (CAS), 
cesses aUocated to that processor. The details and uses ^ 4divi^ible read-modify-write hstruc 
of these data structures are explamed below. ^ ^ instruction which involves two steps, a test 
Operating System step and then a conditional data writing step, which 
..^ ^ TT*«v cannot be interrupted until it is complete. 
All of the CPUs use a modified UNIX operating instance, the TAS instruction can be used to test 
system. (UNIX is a trademark of AT&T BeU Laborato- 35 ^ specified memory location is equal to 
ries.) Full UNIX functionahty is available in all the ^^^^ ^nd. if so, to set it equal to one. Making this in- 
processois. To accomplish this, the UNIX kernel has struction "indivisible" ensures that while processor API 
been modified by dividing or replicating portions of the performs a TAS on memory location X, no other pro- 
kernel among the MP and attached APs, and adding cesser can modify X. Otherwise, another processor, 
new interprocessor communication facilities. The inter- 40 such as MP or AP2 could modify X after API had tested 
processor communication facilities allow requests X's value but before API was able to set X to I. 
which cannot be handled locally (e.g., on one of the An indivisible compare and swap (CAS) instruction 
APs) to be handled by another processor (e.g., the main works similarly to the TAS instruction, except that the 
processor MP). first step compares a ftfst CPU register with a memory 
For those not skilled in the art, it should be known « location, and the second step stores the value in a see- 
that the term "kernel" is generally used to refer to a set ond CPU register into the memory location if the com- 
of software routines, including system routines which parison's test criterion is satisfied, 
handle most of the system's hardware dependent func In addition to the run queue lock, mdivisible read- 
tions-such as disk access and other mput and output modify-wnte mstnictions are used for updatmg all data 
operations. The UNIX kernel is typicaDy copied from ^0 structtires that could otherwise be smiultaneously ac- 

Zk into the system's random ac^memoo^^(e.g., the ^^^^ ^'^^ P/^^^^* 

uia*. uxvw uic DjoMsuj 9 ,„uL\^ZJ Other words, each such data structure must have a cor- 

mam processor's memory MEM_MP) whenever the ^^^^^^^ ^^^^ an indivisible read modify 

system IS restarted. write instruction must be used to test the lock flag bt- 

The main difference between the main processor MP ^^^^ corresponding data structure is updated. Data 

and the applications processors API to APn is that the ^tnictures. such as the USER structure, which cannot 

mam processor MP is the only processor that can per- simultaneously accessed by more than one processor 

form certain, system funcuons. For mstance, the main ^^^^ ^^ds lock protection. As will be understood 

processor is the only one which can access the system's ^y those skilled in the art. an example of another data 
disk storage units 22. 60 structure which requires the use of a lock flag is tiie 

The primary goal for the allocation of system func- sleep queue for each processor, 
tions between the processors is to make the operation of 

each processor as autonomous as the system's hardware Process Table 

configuration will allow. In other words, each AP is In the main processor's memory module there is a 
allowed to perform as many system functions locally as 65 data structure called the process table 30. This table has 

is consistent with the system's hardware. This mini- one row 38 of data for each user process in the system, 

mixes the frequency of interprocessor function calls and including the following data which are used in the pres- 

interprocessor memory access. cat invention. 
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TTierc is a priority parameter 31 which indicates the processor must wait until it is done. To prevent cxces- 

relativc priority of tL process. In the preferred embodi- sive bus trafRc caused by such situafions. if a processor 

ment numcricany low priority parameter values are finds that a run queue is lockwi. it « forced to wait a 

mcd to indicate high process priority. User processes preselected amomit of time (eg. aoi milhseconds) 

are assigned priority values between 127 (the lowest 5 before testing the Run Lock again, 

priority) md 25 (the highest priority), while system If the Run Lock is equal to icro, the run queue is 

tasks are assigned priority values between 24 and 2cro. unlocked and the process performing the test sets the 

Each process in the system is cither actively running. Run Lock before proceeding to modify the processor s 

u waiting to run, or is temporarily inactive. The pro- run queue. When the processor is done with the run 

cesses waiting to run on each processor arc placed on 10 queue, it unlocks the run queue by rest^g the Run 

separate run queues. Similarly, there is a set of sleep Lock to rao. 

queues for temporarily inactive processes, and actively The Preemption Flag parameter 40f^ oscd to force 

running processes arc not on any queue as long as they the processor to look on its run queue for a process of 

are running. higher priority than the curxendy running process. Nor- 

Each run queue is simply a linked list formed using 15 maUy. the search for a new process is performed only 

the queue link parameter 31 in the process table 30. For when the currently running process finishes or reaches 

each CPU there is a CPUSTATE data structure 40 a block (such as a cross processor call) which causes it 

which points to the row 38 of the process table 30 for to stopped, at least temporarily. The current process 

the first process in its run queue. The queue link 31 for can be preempted, however, if the Preemption Flag 40/ 

that process points to the row of the process table for 20 is given a nonzero value. 

the next process in the processor's run queue, and so on. Toward the end of the processing of every interrupt 

The entry for the last process in each run queue has a which can interrupt a user process, the Preemption Flag 

zero in its queue link to indicate that it is at the end of 40/ is checked. If the Preemption Flag is nonzero, a 

the queue. search for a higher priority process than the currentiy 

For each process, the process table 30 also includes a 25 running process is initiated. If a higher priority process 

Home CPU parameter 33 which identifies the assigned is found, the current process is stopped and saved, and 

home CPU for the process, and a Current CPU parame- the higher priority process is run. In any case, at the end 

ter 34 which identifies the current CPU on which it is of the preemption search, the Preemption Flag 40/ is 

running or waiting to run. The Next CPU parameter 35 automatically reset to zera 

is used in cross processor calb to indicate the CPU on 30 The set of interrupts which can initiate a preemption 

which the process is to be run: scaith include the interrupt generated by a processor 

Finally, for each process there is a User Struc param- when it puts a high priority process on the run queue of 

eter 36 which points to the User Structure for the pro- another processor, and a clock interrupt, which occurs 

cess. A separate User Structure, which is a (3072 byte) 64 times per second. 

buffer, is assigned to every process for storing the state 33 Next, the CPUSTATE data structure contains a set 
of the process, certain special parameters, and for hold- of Performance Statistics 40g which, as described be- 
ing a stack called the system mode stack that is used low, are used to help select to a home site for each new 
when the process performs certain system mode func- process created by the system 20. 
tions. The CPUSTATE data structure 40 also contains a list 

While the process table 30 contains other parameters 40 40A of the free pages in its physical memory for use by 

used by the UNIX operating system, only those used for its virtual memory management system: 

cross processor calls are described herein. ^^^^^ Processor Calls 

CPUSTATE Data Structure pjQ 4 is a fiow chart of the process by which a 

FIG. 3 is a block diagram of the CPUSTATE data 45 system subroutine call may cause a process to be moved 

structure used in the preferred embodiment of the pres- from one site to another in a computer system. This is 

ent mvcntion. There is one CPUSTATE data structure essentially a more detailed version of FIG. 2A. 

for each processor in the system. For the purpose of explaining FIGS. 4 through 6, the 

The CPUSTATE data structure for each processor term **the process" is used to refer to the process which 

contains the following parameters. A Run Queue 50 has made a syscall or other subroutine call which has 

Header 40a points to the row of the process table 30 for caused a cross processor call to be made, 

the first process m the processor's run queue. A some- Whenever a syscall (Le., a system subroutine call) is 

what snnpler way to state this is to say that the Run made the system first checks to see if the syscall can be 

Queue Header 40a points to the first process in the run run on the current CPU of the process which made the 

queue for the corresponding processor. 55 call (box 70). If so, the syscall routine is performed 

The Current Proc parameter 406 points to the row of locally (box 86) and, assuming that the process is run- 
process table 30 for the process currently running in the ning on its home CPU (box 88), it returns to the process 
processor. The Last Proc parameter 40c points to the that performed the syscall (box 90). 
row of process table 30 for the last process which ran in If the syscall cannot be performed locally, the folio w- 
the processor before the current process began running. 60 ing steps are performed. The parameter in the process 

The Current Priority parameter AQd is the priority table called Next CPU is set equal to a pointer to a 

value for the process currently running in the processor. processor (i,e., to the CPUSTATE data structure for a 

The Run Lock parameter 40e is a flag which is nor- processor) which can perform the syscall (box 76). 

mally eqtial to zero. Any processor which wants to Then a variable called Old Priority is set equal to the 

update or modify the processor's run queue is required 65 processes priority (box 78) (which is obtained from the 

to check this flag using a TAS instruction before pro- priority entry for the current process in the process 

cecding. If the Rim Lock flag is not zero, then some table) so that this value can be restored after a context 

other processor is modifying the run queue and the first switch is performed. 
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Next, the piocesrt priority is set to ihc highest user Now that the processor wMdi was r^^^ ^ 

«toSlKS^systan(box80).Thisis<toneso P«x«s has been set up wrth • new 

CSnro^vKs^victtl as quickly as possible SWITCH program eontmues by sdttu« ^ the NE^ 

tnat me process wiu nc » m / i~— ^ ^j^^ process which a undergomg the 

^■^^ ^S^"Sh itself is performed by calling a 5 context switch. These steps are performed whenev«a 

ro2^e^l^^^S^ K). which -JdescriLi context switch ^^S^^C^Soi^T) 

Slowindetaflwithreferen^toFIGS.Sa.^6. The <^^ZS:^TSS^<Slo. c^^^ 

process is now running on the processor pomted to^ lasTPrSSu diTorotherwise ready to exit (box 

preferred embodment. the Nex^ CPU ualvrays the ^ ^j^^ ^j,^ ^ 

£tKSr;JSSrSLr^'it SWITCH 

•y*^ . ,.u ^- ♦»,.«r^«:c'c Otherwise, if the process (called LAST PROQ is 

Once the coatext ^^^^J^^L"^^ 15 being moved to a new CPU ftc-, its NEXT CPU is not 

original priority is restor^(boE 84) and the syscaU ^ CURRENT CPUD (box 117) the 

routine b performed (86). Then thcproccss is r^«i sETRQ routine is caDed (box 120) to move the process 

to its home dtc (boxes 88 to 94)- This is done by first ^ LAST PROC to its home site, 

checking to see if the current CPU is the processs ^ ^ ^^^^ ^^^^ SWITCH is bdng sus- 

Home CPU (box 88). 2o pended Ce., bemg put on a sleep queue) or is not 

If the Current CPU is the process s Home CPU, no ^[^t^hing processors for any other reason (box 117) 

further processing is required and the routine returns SWITCH routine exits instead of calling 

(box 90). Otherwise a context switch back to the pro- sETRQ. Thus the SWITCH is used not only for con- 

cess's Home CPU is performed by setting the Next CPU ^^^^ switching, but also for activating a new process 

parameter equal to the process's Home CPU (box 92), ^ whenever a CPU's currently running process is sus- 

calling SWITCH (box 94), and then returning (box 90). ^^nd^ 

In the preferred embodiment of the invention, the ^ a flow chart of the subroutine SETRQ 

restoration portion of the syscall handling routine, which is used by the context switching method dia- 

boxes 88 to 94, is kept simple because (1) there is only gjamed in FIG. 5. The SETRQ routine receives as a 

one processor to which processes are sent for handling parameter a pointer to a process which needs to be put 

special functions 0^-, the main processor), and (2) none ^^^^ ^ q^^^^ of its NEXT CPU. as identified by 

of the syscall routines call other syscall routines. As a g^^^ process table 30 (FIG. 1) for that pro- 
result, a process is always returned to its Home CPU 

after a syscall is complete. The first step (box 130) of the SETRQ routine is to 

As will be understood by those skilled in the art, in 35 queue of the process's NEXT CPU, using 

other embodiments of the invention a process might gn indivisible TAS instruction on the Run LOCK for 

"return" to a CPU other than the process's Home CPU. that CPU. As indicated above, if the Run LOCK for the 

In such a system a *Tlctum CPU" parameter would NEXT CPU is already locked, the system waiis for a 

have to be added to the system. In such a system, box 88 short period of time and then tries the TAS instruction 

win be replaced by a query regarding whether "Current 40 again, repeating this process until the Run LOCK is 

CPU=Retum CPU?", and if not, the process will be unlocked by whatever process was previously using it. 

SWITCHed to the Return CPU, which may or may not once the NEXT CPU's run queue is locked, the 

be the Home CPU. routine checks to see if the Current CPU is the same as 

FIG. 5 is a flow chan of the SWITCH routine used in the NEXT CPU (box 132). If so, the process is simply 

the preferred embodiment of the invention to move a 45 added to the run queue of the current (Le., NEXT) CPy 

process from one site to another in a computer system. (box 136) and the run queue for the NEXT CPU is 

The first step (box 100) of this routine is to save the unlocked (box 138) by setting its Run LOCK to zero, 

context of the current process by storing its registers if the current CPU is not the same as the NEXT CPU 

and such in its USER data structure (see RG. 1). (box 132) then the Preemption Flag of the NEXT CPU 

Then the run queue for the Current CPU is locked 50 is set and the NEXT CPU b sent a software interrupt 

(using the the RUN LOCK 40e in the CPUSTATE data (box 134). Then the Current CPU parameter is set equal 

structure for the Current CPU) (box 104) and the LAST to NEXT CPU, the process is added to the run queue of 

PROC parameter 40c is set equal to CURRENT PROC the NEXT CPU (box 13Q and the NEXT CPU's run 

40*. This reflects the fact that the current process will queue is unlocked. 

no longer be running, and hence will be the last process 55 The purpose of setting the Preempt Flag and generai- 

to have run. ing an interrupt for the NEXT CPU (box 134) is to 

Next the CURRENT PROC parameter 40* is set force the NEXT CPU to service the process as soon as 

equal to a pointer to the process on the run queue with possible. This combination of steps forces the NEXT 

the highest priority, and the CURRENT PRIORITY CPU to preempt the currently running process with the 

parameter 40<f is set equal to this new process's priority 60 process added to the run queue, which has been given 

(box 108). Then the new CURRENT PROC is re- the highest user priority (see box 108 in FIG. 5). The 

moved from the run queue (by modifying the run reason that the interrupt is sent to the NEXT CPU 

queue's linked list usmg standard programming tech- before the process is added to the NEXT CPU's run 

niques) (box 110) and the Current CPU's run queue is queue is simply to speed up the process of transferring 

unlocked (box 112) by setting the RUN LOCK parame- 65 the process to the NEXT CPU. In effect, the NEXT 

ter 40e to zero. Finally, the new current process is CPU is forced to begin the process of looking for a new 

started up by restoring tiic process's context from its process as soon as possible, but will not actually look 

USER structure and "resuming" the process (box 114). through its run queue for the highest priority process 
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thcrdn unta its ran queue is unlocked several instruc- For purpose of efficient operation, a copy of the 

tion cydes later. portions of the UNIX kernel used by each application 

processor b copied into local memory* This is done so 

Process Creation and Home Site Selection that each processor can run kernel code without having 

Referring to FIG. 7, new processes are created in 3 to perform nonlocal memory access, which is very slow 

UNIX systems by a two stq) process: a fork (box 150) compared to local memory access, 

which duplicates an already existing process, and an The process by which the kernel code is copied to 

-exec" step 0>ox 152) which replaces the duplicated local memory is as follows. 

process's control program with a program from a sped- FIG. 8 is a block diagram of a virtual memory man- 

ggjlgj^ 10 agement page table used in the preferred embodiment of 

In systems incorporating the present invention, pro* the present invention. The use of page tables by the 

cess creation requires an additional step: selection of a memory management units is well known in the prior 

home dtc for the new process. In the preferred cmbodi- art However, the present invention makes special use 

ment, the sdection of a home site worics as follows. of this table. 

First (box 154X the process inspects the HOME- For each page entry in the MMU page table there is 

MASK pammft^ for the new process. The HOME- a space for storing a real (ue,, physical) memory ad- 

MASK parameter is loaded into the new process's dress, a **v" flag which in d ica t es if the real memoiy 

USER structure when the process b created from die address b valid (hc^ it indicates whether the page is 

paren process at the fork step (box 150). It is amask that cnrtently stored in resident memory), a read only RO 

indicates which CPUs the new process can use as a ^ flag which indicates, if enabled, that the corresponding 

home site. In particular, each bit of the HOMESITE page cannot be overwritten; a MOD flag, which is 

parameter is equal to 1 if the corresponding CPU can be enabled if the contents of the page have been modified 

used as a home site, and is equal to 0 if is can't since the page was fint allocated; and a REF flag, 

The remamder of the home site selection process is which is enable if the contents of the page have been 

restricted to sites allowed by the process's HOME- accessed in any way (Le., dther read or written to) since 

SITE. the page was first allocated. 

' Second (box 156), the system calculates the expected When the system is first started up. the MMU Page 

memory usage of the new process for each of the pro- Tables in each processor contain entries for all of the 

cessors permitted by its HOMESITE parameter. The ^ UNIX kemd code, with real addresses in the main 

process may use less memory in some processors than in processor's memory MEM— MP. Every five seconds, a 

others because it may be able to share code already special program in the main processor writes into local 

resident at those sites. memory a copy of all the kernel pages which have been 

Third (box 158). the system picks two candidate sites: referenced by each applications processor and which 

(I) the site which would have the most memory left if 35 have not yet been copied into local memory. References 

the process were located there; and (2) the site with the to these pages are thereafter handled by reading local 

smallest average run queue size which also has enough memory rather than the main processor's memory, 

memory to run the process. - While the present invention has been described with 

Fourth (boxes 160-164), the system selects as the reference to a few specific embodiments, the descrip- 

process*s home site, the fiirst candidate if its average 40 tion is illustrative of the invention and is not to be con- 

queue size is less than the the second candidate's aver- strued as limiting the invention. Various modifications 

age queue size plus a preselected quantity QZ (a system may occur to those skilled in the art without departing 

parameter selected by the person setting up the system, from the true spirit and scope of the invention as defined 

typically equal to 0.5). Otherwise the second candidate by the appended claims. 

site is selected as the home site. 45 For instance, in other embodiments of the present 

It should be noted that the average queue size for invention, the system's functions could be distributed in 

every processor is stored in the Performance Statistics such a way that different syscall routines might require 

pcHtion 40^ of the processor's CPUSTATE data struc- cross processor calls to a plurality or multiplicity of 

turc, and is updated by the system's clock routine sixty- different corresponding processors, 

four times per second. 50 ^ somB embodiments of the present invention 

Also, it can be seen that the selection of a home site is there could be a dynamic load balancer which would 

generally weighted in £avor of sites with the most mem- periodically compare the loads on the various proces- 

ory available. sors in the system. The load balancer would be pro- 

Finaily (boxes 166-168) the new process is moved to granuned to select candidate processes for being shifted 

its new home site (if it isn*t already there), by setting its 55 to new home sites, and to transfer a selected process to 

HOME CPU parameter to the new site, copying its a new home site if the load on its current home site 

USER structure and resident memory into the memory becomes, much heavier than the load on one or more of 

of the home site, and putting the new process on the the other processors in the system, 

home site's run queue by calling SETRQ (not shown as What is claimed is: 

a separate step in FIO. 7). 60 1. A computer system, comprising: 

a multiplicity of distinct central processing units 

Memory Management (CPUs), each having a sq>arate. local, random 

The UNIX kernel is initially copied from disk into the access memory means to which said CPU has di- 

main processor's random access memory MEM_MP rect access; 

whenever the system is restarted. The other processors 65 at least one interprocessor bus coupling said CPUs to 

initiaUy access ^e kernel's routines by performing non- said multiplicity of memory means, so that each 

local mdonory accesses over the syststem composition CPU can access both its own local memory means 

bus 24 to MEM—MP. and the memory means of the other CPU^ . 
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nm queue means coupled to said CPUs for holding a 
separate run queue for each of said CPUs; each said 
run quaie holding a list of the processes waiting to 
run on the corresponding CPU; 

process creation means in at least one of said CPUs 
for creating new processes, for assigning one of 

. said CPUs as the home site of each Jiew process, 
and for installing said new process in the local 
memory means for said home sixc; and 

cross processor caU means in each of said CPU^for 
temporarily transfenmg a specified process from 
its home site to another one of said CPUs, for the 
purpose of performing a task which cannot be per- 
formed on «ud home site;, said cross processor call 
means including means fon 

(a) placing said specified process on the run queue 
of said other CPU; 

(b) continuing the execution of said specified pro- 
cess on said other CPU, using the memory means 
for said specified process's home site as the resi- 
dent memory for said process and using said 
interprocessor bus means to couple said other 
CPU to said home site memory means, until a 
predefined set of tasks has been completed; and 
then 

(c) upon completion of said predcfmed set of tasks, 
automatically returning said specified process to 
its home site by placing said specified process on 
the run* queue of said specified process's home 
site, so that execution of the process will resume 
on said specified process's home site. 

2. A computer system as set forth in claim I, wherein 
said random access memory means of a first one of 

said CPUs includes kernel means having a prede- 
fined set of software routines for performing prede- 35 
fined kernel functions; 
said computer system fiuther including 
memory management means coupled to said ran- 
dom access memory means of said CPUs, incUid 
ing 

table means for denoting which portions of said 
kernel means are used by each of said CPUs 
other than said first CPU; and 

kernel copy means, coupled to said table means, for 
periodically copying into the local random ac* 
cess memory means of each of said other CPUs 
said kernel portions denoted in said table means 
as used by said CPU but not previously copied 
into the local random access memory means of 
said CPU; 

whereby the use of said interprocessor bus for access- 
ing said kernrf means is reduced by providing cop- 
ies, in the local memory means of each CPU, of 
those portions of said kernel means actually used 
by each CPU. 

3. A computer system as set forth in claim 1, wherein 
said process creation means includes means for as- 
signing a home site priority to each new process, 
said home site priority being assigned a value 
within a predefined range of priority values; 

said system further includes process selection means 
for selecting a process to run on a specified one of 
said CPUs, when the process currentiy running in 
said specified CPU is . stopped, by selecting the 
process in said nm queue for said specified CPU 65 
with the highest priority; and 

said cross processor call means further includes 
means for 



(d) assigning a specified process a higher priority 
than its home site priority when it ts added to the 
run queue for a CPU other than its home sit^ 
and 

(c) resetting the priority for said specified process 
to its home site priority when said process is 
added to the run queue for its home sit^ . 
whereby a process transferred to a CPU other than its 
home site is given increased priority to accelerate 
selection of the process for running on said other 
CPU. 

4. A computer system as set forth m claim 3, wberdn 
at least one of said CPUs includes preemption means for 
finding the highest priority process in its run queue, said 

15 preemption means including means for stopping the 
process currentiy running said CPU, when said highest 
priority process has higher priority than the. procKS 
currentiy running in said CPU, and then running said 
hi^iest priority process; 
at least one of said CPUs includes interrupt means for 
activating said preemption means in another one of 
said CPUs; and 
said cross processor call means further includes 
means for 

(0 using said interrupt means in said specified pro- 
cess's home site CPU to activate said preemption 
means in a specified CPU when said specified pro- 
cess is added to the run queue for said specified 
CPU; 

whereby a process transferred to a CPU other than its 
home site will be run immediately if its assigned 
priority is greater than the priorities assigned to the 
process currently running in said other CPU and to 
other processes, if any, in said nm queue for said 
otiier CPU. 

5. A computer system, comprising: 
a multiplicity of distinct central processing units 

(CPUs), each having a separate, local, random 
access memory means to which said CPU has di- 
40 rect access; said CPUs having the capability of 
executing indivisible read modify write instruc- 
tions; 

at least one interprocessor bus coupling said CPUs to 
all of said memory means, so that each CPU can 
access both its own local memory means and the 
memory means of the other CPUs; 
nm queue means coupled to said CPUs for holding a 
separate run queue for each of sdd CPUs; each said 
run queue holding a list of the processes waiting to 
run on the corresponding CPU; 
a run lock for each said run queue, said nm lock 
having a first predefined value to indicate that the 
corresponding run queue is not in the process of 
feeing modified by any of said CPUs and is un- 
locked, and a value other than said fust predefined 
value when the corresponding run queue is being 
modified by one of said CPUs and is therefore 
locked; 

run queue updating means coupled to said CPUs for 
adding or removing a specified process from a 
specified run queue, said run queue updating means 
including means for: 
(a) locking said specified nm queue by 
(a,l) using an indivisible read modify write in- 
struction to test the value of the run lock for 
said specified run queue and, if said run lock 
value indicates that said specified run queue is 
unlocked, to set said run lock to a value which 
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. m 4ic 8 tCT that said spedfied nm queue is 
; locked; and ' 

(a^) if the test in step (a,l) dctenniries that said 
nm quote is locked, performing step (a^l) 
again after a predefined delay, until the test in S 
step (al) determines that said ran queue is 
unlocked; 

(b) adding or removing a spec i fied process from 
said specified nm queue; and 

(c) unlocking said specified run queue by setting 10 
said run lock for said ^)ecified run queue to said 
fim predefined value; 

process creation means in at least one of said CPUs 
for creating new processes, for assigning one of 
said CPUs as the home site of each new process, IS 
and for installing said new process in the local 
memory means for said home sit^ and 

cross processor call means in each of said CPUs for 
temporarily transferring a specified process &om 
its home site to a specified one of said other CPUs, 20 
for the purpose of perfonning a task which caimot 
be performed on said home site, said cross proces- 
sor call means including means for: 

(a) using said run queue updating means to add said 
specified process to the run queue of said speci- 25 

. fiedCPU; 

(b) continuing the execution of said specified pro- 
cess on said specified CPU, using the memory 
means for said specified process's home site as 
the resident memory for said process and using 30 
said interprocessor bus means to couple said 
specified CPU to said home site memory means, 
until a predefmed set of tasks has been com- 
pleted; aad then 

(c) upon completion of said predefined set of tasks, 35 
automatically returning said specified process to 
its home site by using said run queue updating 
means to add said specified process to the run 
queue of said specified process's home site, so 
that execution of the process will resume on said 40 
specified process's home site. 

6. A computer system as set forth in claim 5, wherein 
said process creation means includes means for as- 
signing a home site priority to each new process, 
said home site priority being assigned a value 45 
within a predefined range of priority values; 

said system further includes process selection means 
for selecting a process to run on a specified one of 
said CPUs, when the process currently running in 
said specified CPU is stopped, by selecting the 50 
process in said run queue for said specified CPU 
with the highest priority; and 

said cross processor call means further includes 
means for 

(d) assigning a specified process a higher priority 55 
than its home site priority when it is added to the 
run queue for a CPU other than its home site; 
and 

(e) resetting the priority for said specified process to 
its home site priority when said process is added to 60 
the run queue for its home site; 

whereby a process transferred to a CPU other than its 
home site is given increased priority to accelerate 
sdection of the process for nmning on said other 
CPU. 63 

7. A con^)uter system as set forth in claim 6, wherein 
at least one of said CPUs includes preemption means 

for finding the highest priority process in its run 
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queue, said preemption means indnding means for 
stopping the process currently nmning said CPU, 
when said hig^t priority process has higher prior- 
ity than the process curreiUly running in said CPU, 
and then running said highest priority process; 

at least one of said CPUs includes interrupt means for 
activating said preemption means in another one of 
said CPUs; and 

said cross processor call means further includes 
means for 

(0 using said interrupt means m said specified pro- 
cess's home site CPU to activate said preemption 
means in a specified CPU when said specified 
process is added to the run queue for said speci- 
fied CPU; 

whereby a process transferred to a CPU other than its 
home site will be run immediately if its assigned 
priority is greater than the priorities assigned to the 
process currently running in said other CPU and to 
other processes, if any, in said run queue for said 
other CPU. 

8. A computer system, comprising: 

a multiplicity of distinct central processing units 
(CPUs), each having a separate, local, random 
access memory means to which said CPU has di- 
rect access; said CPUs having the capability of 
executing indivisible read modify write instruc- 
tions; 

at least one interprocessor bus coupling said CPUs to 
all of said memory means, so that each CPU can 
access both its own local memory means and the 
memory means of the other CPUs; 

process creation means coupled to said CPUs, for 
creating new processes, for assigning one of said 
CPUs as the home site of each new process, for 
installing said new process in the local memory 
means for said home site, and for assigning a home 
site priority to each new process, said home site 
priority being assigned a value within a predefined 
range of priority values; 

run queue means coupled to said CPUs for holding a 
separate nm queue for each of said CPUs; each said 
run queue holding a list of the processes waiting to 
run on the corresponding CPU; 

process table means coupled to said CPUs for retain- 
ing information reganfing every process running or 
otherwise in existence in said system, including for 
each said process 

a HONfE CPU parameter which indicates the 

home site of said process; 
a CURRENT CPU parameter which indicates the 

current CPU on which said process is running, 

waiting to run, or otherwise residing; and 
a PRIORITY parameter indicative of the priority 

of said process; 
cpustate table means for storing information regard- 
ing each said CPU, including: 
a run queue header identifying the run queue for 

said CPU; 

a current process parameter identifying the process 
currently running in said CPU; 

a last process parameter identifying the process 
which was run prior to the process currently 
running in said CPU; and 

a run lock parameter which is given a first prede- 
fined value to indicate that the corresponding 
run queue is not in the process of being modified 
by any of said CPUs and is unlocked, and a value 
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other than said first predefined value when the 
corresponding nm quene is bong modified by 
one of said CPUs and is therefore locked; and 
nm quene updatmg means coupled to said CPUs for 
adding or removing a specified process from a 5 
specified run qiieue» said run queue updating means 
i^uding means for 

(a) locking said specified nm queue by 

(a,i) using said indivisible read modify write 
instruction to test die value of the run lock for 
said specified run queue and, if said run lock 
value indicates that said specified run queue is 
unlocked* to set said run lock to a value which 
indicates that said specified run queue is 
locked; and 

(a,2) if the test in step (a,l) determines that said 
ron queue is locked, performing step (a,l) 
after a predefined delay, until the test in 
step (al) determines that said run queue is 
unlocked; 

(b) adding or removing a specified process from 
said specified run queue; 

(c) unlocking said specified run queue by setting 
said run lock for said specified run queue to said ^ 
first predefined value; and 

(d) updating said run queue header, current process 
and last process parameters of the cptistate table 
means for the CPU corresponding to said speci- 
fied run queue to reflect the current status of said yQ 
CPU; 

process selection means in at least one of said CPUs 
for selecting a process to run on a specified one of 
said CPUs when the process currently running in 
said specified CPU is stopped, including means for 35 
selecting the process in said run queue for said 
specified CPU with the highest priority and means 
for initiating the running of said selected process in 
said specified CPU; and 

preemption means in each CPU for finding the high- 4Q 
est priority process in its run queue, said preemp- 
tion means including means for stopping the pro- 
cess currently running in said CPU, when said 
highest priority process has higher priority than 
the process currently running in said CPU, and 45 
then running said highest priority process; 

interrupt means in each said CPU for acdvadng said 
preemption means in a specified one of the other 
CPU^ and 

cross processor call means in each of said CPUs for so 
temporarily transferring a specified process from 
its home site to a specified one of said other CPUs, 
for the purpose of performing a task which cannot 
be performed on said home site, said cross proces- 
sor call means including means for: ss 

(a) using said run queue updating means to add said 
specified process to the run queue of said speci- 
fied CPU; 

(b) assigning said specified process a higher prior- 
ity than its home site priority when it is added to 60 
said run queue for said specified other CPU; 

(c) using said interrupt means in said specified pro- 
cess's home site CPU to activate said preemption 
means in said specified CPU when said specified 
process is added to said run queue for said ^>eci- 65 
fied CPU, so that said specified process will be 
preempt the process ctirrently running in said 
specified CPU; 



18 

(d) continuing the execution of said specified pro- 
cess on said specified CPU, usmg the memory 
means for said specified process's home site as 
the resident memory for said process and using 
said interprocessor bus means to couple said 
specified CPU to said home site memory means, 
until a predefined set of tasks has been com- 
pleted; and then 

(e) upon completion of said predefined set of tasks, 
automatically returning said specified process to 
its home site by ttsing said run queue updating 
means to add said specified process to the run 
queue of said specified process's home site, so 
that execution of the process wDl resume on said 
specified process's home site; and 

(0 resetting the priority for said specified process 
to its home site priority when said process is 
added to said run queue for its home site. 
9. A method of running a multiplicity of processes in 
computer system, comprising the steps of: 
providing a computer system having ' 
(1) a multiplicity of distinct central processing units 
(CPUs), each having a separate, local, random 
access memory means to which said CPU has 
direct access; said CPUs having the capability of 
executing indivisible read modify write instruc- 
tions; and 

(2) at least one interprocessor bus coupling said CPUs 
to all of said memory means, so that each CPU can 
access both its own local memory means and the 
memory means of the other CPUs; 
wherein at least one of said CPUs is capable of 
performing one or more tasks thai at least one of 
said other CPUs cannot perform; 

generating a run queue data structure for holding a 
separate run queue for each of said CPUs; each said 
run queue holding a list of the processes waiting to 
run on the corresponding CPU; 

providing run queue updating means for adding or 
removing a specified process from a specified run 
queue; 

creating new processes, as the need arises, including 
the step of assigning one of said CPUs as the home 
site of each new process, and installing said new 
process in the local memory means for said home 
site; and 

when one of said processes needs to perform a task 
which cannot be performed on its home site, per- 
forming a cross processor call to temporarily trans- 
fer said process from its home site to a specified one 
of said other CPUs which is able to perform said 
task, be performing the steps of: 

(a) using said run queue updating means to add said 
process to the run queue of said specified CPU; 

(b) continuing the execution of said process on said 
specified CPU, using the memory means for said 
process's home site as the resident memory for 
said process and using said interprocessor bus 
means to couple said specified CPU to said home 
site memory means, until a predefined set of tasks 
has been completed; and then 

(c) upon completion of said predefined set of tasks, 
automatically returning said specified process to 
its home site by using said run queue updating 
means to add said process to the nm queue of 
said process's home site, so that execution of the 
process will resume on said process's home site. 
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10. A method as set forth in claim 9» f^irtber incindiog 
the step of generating a ran lock flag for each said run 
queue, said run lock having a first predefined value to 
iti<f|gfltg that the oonesponding run queue is not in the 
process of being modified by any of said CPUs and is ^ 
unlodud. and a value other than said first predefined 
value when the coneq)OQding run queue is being modir 
fied by one of said CPUs and is therefore locked; 

wherein said step of providing run queue updating 
means includes providing run queue updating 
means for adding or removing a specified process 
from a specified.run queue by performing the steps 
of: 

(a) locking said specified run queue by 15 
(a,l) using said indivisible read modify write 

instruction to test the value of the run lock for 
said specified run queue and, if said run lock 
value tndir^**^ that said specified run queue is 
unlocked, to set said run lock to a value which 20 
indicates that said specified run queue is 
locked; and 

(a,2) if the test in step (a,l) determines that said 
run queue is locked, performing step (a,i) 
again after a predefined delay, until the test in 
step (al) determines that said run queue is 
unlocked; 

(b) adding or removing a specified process from 
said specified run queue; and 

(c) unlocking said specified run queue by setting 
said run lock for said specified nm queue to said 
first predefined value. 

11. A method as set fonh in claim 9, wherein said step 
of creating new processes includes assigning a home site 
priority to each new process, said home site priority 
being assgned a value within a predefined range of 
priority values; 

said method further including the step of selecting a 
process to run on a specified one of said CPUs, ^ 
when the process currently nmning in said speci- 
fied CPU is stopped, by selecting the process in 
said run queue for said specified CPU with the 
highest priorit>^ and 

said step of performing a cross processor call further 45 
includes the steps of 

(d) assigning a specified process a higher priority 
than its home site priority when it is added to the 
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run queue for a CPU other than its home site; 
and 

(e) resetting the priority for said specified process to 
its home site priority when said process is added to 
the run queue for its home site; 

whereby a process transferred to a CPU otho- than its 
home site is given increased priority to accelerate 
selectica of the process for running on said other 
CPU. 

li. A method as set forth in claim 11, wherein said 
step of performing a cross processor call further in- 
cludes the step of 

(f) generating a. preemption interrupt in said speci- 
fied CPU when said specified process is added to 
the run queue for said specified CPU; 
said method further including the step of responding 
to a preemption interrupt in a spedfied CPU by: 

(a) finding the highest priority process in the run 
queue of said specified CPU; and 

(b) stopping the process currently running in said 
CPU, when said highest priority process has 
higher priority than the process currently run- 
ning in said CPU, and then running said highest 
priority process; 

whereby a process transferred to a CPU other than its 
home site will be run immediately if its assigned 
priority is greater than the priorities assigned to the 
process currently running in said other CPU and to 
other processes, if any, in said run queue for said 
other CPU. 

13. A method as set forth in claim 9, further includmg 
the steps of: 

providing a predefined set of kerne! routines in said 
local memory means of a first one of said CPUs; 

denoting, in a predefined data structure, which of said 
kernel routines are used by each of said CPUs other 
than said first CPU; and 

periodically copying into the local random access 
memory means of each of said other CPUs said 
kernel routines denoted in said predefined data 
structure as used by said CPU but not previously 
copied into the local random access memory means 
of said CPU; 

whereby the use of said interprocessor bus for access- 
ing said kernel routines is reduced by providing 
copies, in the local memory means of each CPU, of 
those kernel routines actually used by each CPU. 
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